Hello,
Having ‘mmap’ bindings would be much welcome.
Maxime Devos <maximede...@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’.
