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

[Daniel Hartwig]

On 30 April 2013 22:23, Nala Ginrut <address@hidden> wrote:
> But I still recommend that store 'size' & 'flags', which need a new
> record-type and to write some helper functions, but very less code.

And have you considered that you can munmap only some sections, how is
that going to work with your proposed struct and flags?

It is a low-level, posix interface.  The most sensible thing to do is
just return the pointer, let the user handle and track it however is
appropriate for them.

> Apologies if this is well-known and I just forgot it, but can
> bytevectors be read-only? I think we'd need that to handle
> read-only mmap'ed memory. (If not, I hope we could allow
> read-only bytevectors.)

No need, and complicating the implementation anyway.  Attempts to
write read-only memory is simple “an error”, which may or may not
generate a posix error.  Again, this is low-level stuff, it is enough
to leave the responsibility to the user who was the one to specify the
constraints in the first place.  Think of all the interfaces that can
possible wrap the mmaped region: bytevectors, ports, strings, arrays …
it becomes impossible to handle with assurance, except that if a write
(or other invalid operation) makes its way to a system call, it may
produce a posix error which is the catch all.

There is also the performance consideration, where potentially
multiple guile-level error checks (due to nested data types) will
occur on every access.  At that point, you are now losing some of the
benefits of having the mmap in the first place.

Low-level stuff, if you hurt yourself, thats just too bad.