Re: mmap for guile

[Ludovic Courtès]

Hello,

Having ‘mmap’ bindings would be much welcome.

Maxime Devos <maximedevos@telenet.be> skribis:

> +SCM_DEFINE (scm_mmap_search, "mmap/search", 2, 4, 0, 
> +            (SCM addr, SCM len, SCM prot, SCM flags, SCM fd, SCM
> offset),
> +         "See the unix man page for mmap.  Returns a bytevector.\n"
> +         "Note that the region allocated will be searched by the
> garbage\n"
> +         "collector for pointers.  Defaults:\n"
>
> I think it would be a good idea to document it will be automatically
> unmapped during GC, as this is a rather low-leel interface

Agreed.

I was wondering about offering an explicit ‘munmap’ interface: it would
be useful for fine-grain OS resource management, just like ‘close-fdes’.

Doing that naively would mean that one can trivially get a pure Scheme
program to segfault, which is contrary to what we do.

But we could provide special semantics: the bytevector would become
zero-length (possible, but weird, as Maxime points out), or it would be
turned into a /dev/zero mapping (weird as well).

Thoughts?

> Also, what if you mmap a region, use bytevector->pointer and pass it to
> some C thing, which saves the pointer somewhere where boehm-gc can find
> it and boehm-gc considers it to be live, is there something that
> prevents boehm-gc from improperly calling the finalizer & unmapping the
> region, causing a dangling pointer?

There’s a risk, but I don’t think it’s specific to mmap.

> Also, WDYT of using ports instead of raw fds in the API?  That would
> play nicer with move->fdes etc.

Agreed.

>>+  /* Invalidate further work on this bytevector. */
>>+  SCM_BYTEVECTOR_SET_LENGTH (bvec, 0);
>>+  SCM_BYTEVECTOR_SET_CONTENTS (bvec, NULL);
>
> Possibly Guile's optimiser assumes that bytevectors never change in
> length (needs to be checked).  So unless the relevant optimiser code is
> changed, and it is documented that bytevectors can change in length, I
> think it would be safer to not have an unmapping procedure in Scheme
> (though a procedure for remapping it as /dev/zero should be safe).

I don’t think the optimizer makes any such assumption, except for
literal bytevectors.

Besides what Maxime points out, some more superficial issues:

  • In documentation, please refer to the relevant glibc section instead
    of “See man page” (info "(libc) Memory-mapped I/O").

  • Please update doc/ref with a section on memory-mapped I/O.

  • Make sure to follow the GNU coding in C: space before opening paren,
    braces on a line of their own, etc.

Since you already have a copyright assignment on file, there won’t be
administrative delays, which is a good thing.  :-)

I hope we can have those ‘mmap’ bindings soonish!

Thanks,
Ludo’.