Re: [Lush-devel] Why are memory-mapped storages read-only?

[Yann L. <ya...@cs...>]

Cool!

  -- Yann

On Monday 16 November 2009, Ralf Juengling wrote:
> FYI, this is implemented now. I have changed the storage-API
> a bit: You now need to decide what kind of storage you want
> when you create it. The storage kind may not be changed later.
> 
> 
> ? ^Anew-storage
> Search Results for: new-storage
>    1. (new-storage <et>)
>    2. (new-storage/managed <et> <n> [<init>])
>    3. (new-storage/mmap <et> <file> [<offs> [<readonly>]])
>    4. (new-storage/foreign <et> <n> <p> [<readonly>])
> choice> 3
> 
> Each "constructor function" and what it creates:
> 
> <new-storage>         : an empty storage,
> <new-storage/managed> : a storage object for memory managed by lush
> <new-storage/mmap>    : a storage associated with a file, and
> <new-storage/foreign> : a storage associated with memory managed
>                          by someone else (e.g., a 3rd-party library)
> 
> An empty storage may be associated with "managed memory" only
> (using <storage-alloc>).
> 
> 
> ------------------------------------------------------------------------
> (new-storage/mmap <et> <file> [<offs> [<readonly>]])         (storage.c)
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> 
> * See: storage-readonlyp
> Map file into memory and associate that memory with a storage with
> element-type et ; return the storage.
> 
> File may be a file descriptor or a string containing a filename. Each
> element of the file starting at byte offs is made accessible through the
> corresponding element of the storage srg . Storages of storage class
> AtomStorage or MptrStorage cannot be memory mapped. Mapped storages are
> readonly by default (pass () as fourth argument to create a writeable
> mmapped storage).
> 
> 
> = ()
> ?
> 
> On Wed, 2 Sep 2009, Yann LeCun wrote:
> > The mmap functionality was implemented to allow access to
> > large data files without having to explicitely load them
> > into RAM in advance. Back in the old days of Solaris, if
> > you mmapped in read-only mode, the swapping system was
> > smart enough to never swap out. Hence you would save
> > a lot on disk (or network) bandwidth.
> >
> > Also, you really don't want a random bug in a Lush program
> > to inadvertently corrupt your dataset file on disk......
> >
> > That said, we could have two types of mmapped storages:
> > one for read only, and one for read/write.
> >
> >  -- Yann
> >
> > Leon might remember. I seem to rememberthink writing to mmapped storages
> > used to crash on Solaris
> >
> > On Wednesday 02 September 2009, Ralf Juengling wrote:
> >> Hi,
> >>
> >> Does anyone remember why lush does not allow to
> >> manipulate memory mapped storages?
> >>
> >> Ralf
> >>
> >>
> >> ------------------------------------------------------------------------
> >>--- --- Let Crystal Reports handle the reporting - Free Crystal Reports
> >> 2008 30-Day trial. Simplify your report design, integration and
> >> deployment - and focus on what you do best, core application coding.
> >> Discover what's new with Crystal Reports now. 
> >> http://p.sf.net/sfu/bobj-july
> >> _______________________________________________
> >> Lush-devel mailing list
> >> Lus...@li...
> >> https://lists.sourceforge.net/lists/listinfo/lush-devel
>