guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Feature Request] Some ideas on 'mmap'


From: Nala Ginrut
Subject: Re: [Feature Request] Some ideas on 'mmap'
Date: Wed, 01 May 2013 23:25:40 +0800

On Wed, 2013-05-01 at 18:54 +0800, Chaos Eternal wrote:
> but howto protect your pointer ?
> 

There's no bared pointer after pointer->bytevector or wrapped with
record-type. Anyway, since Guile can't operate pointers directly, so
it's no need to compare with C about 'protect pointer'.

> Also, mmap-ed spaces can hardly be GCed, this will introduce extra 
> complexities.
> 

It's not 'hardly GCed', it has to be closed/munmap explicitly, just like
python's mmap does.

> still see no extra necessary in compare to ports.
> 
> On Tue, Apr 30, 2013 at 10:23 PM, Nala Ginrut <address@hidden> wrote:
> > On Tue, 2013-04-30 at 21:57 +0800, Daniel Hartwig wrote:
> >> On 30 April 2013 21:49, Nala Ginrut <address@hidden> wrote:
> >> > If I use bytevector instead, it means I have to read all the content
> >> > from a file first. I don't think it's the same with mmap in POSIX.
> >> > mmap is used for very large data I/O, if we decide to read them all, we
> >> > lose the game.
> >> > mmap does lazy disk I/O automatically for the file.
> >> >
> >>
> >> With the pointer that mmap returns you can pointer->bytevector.  This
> >> will not read any of the file.
> >
> > Ah~nice! That's the critical hint to reduce the work.
> > Yes, after mmap, we don't need other things anymore.
> > But I still recommend that store 'size' & 'flags', which need a new
> > record-type and to write some helper functions, but very less code.
> >
> > What other guys think?
> >
> > And I'm amazing by the cool of Guile, again. ;-P
> > Thanks!
> >
> >
> >





reply via email to

[Prev in Thread] Current Thread [Next in Thread]