On 30 April 2013 22:23, Nala Ginrut <nalagin...@gmail.com> 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.