Re: mmap in guile -- guile memory management question

[Daniel Ridge]

Ludovic,

On Nov 13, 2006, at 9:43 AM, Ludovic Courtès wrote:

-- trimmed earlier discussion of mmap --

> ... Also, just because it is mapped into the application's
> address space doesn't mean that it actually consumes (memory)  
> resources ...
> That said, it is true that the mmapped region would have to be  
> munmap'ed
> at some point.  One solution might be to pass the u8vector to a  
> guardian
> and invoke munmap when the guardian returns the u8vector.  However,
> since the "destructor" of the u8vector expects to be able to call  
> `free ()'
> on the vector's contents, you would need a hack to make sure that  
> `free ()'
> is never actually called.  Keeping the vector itself forever once it's
> been returned by the guardian (and munmap'd) might be a solution, but
> it's far from elegant.

The entire point of my mmap binding is to create memory objects for  
sparse random accesses.

If you look at the Scheme fragment I originally posted, you will
see that I did create a guardian for managing mmaped objects at reap  
time. Although I did not use a hack to prevent the free, I did use a  
hack to paste a valid, free()able object into the string before the  
free().

What I would really like is the way in guile to create a string or a  
u8vector whose C data will not ever be free()ed by the garbage  
collector -- but I may be a user community of 1 on this point. What  
about relaxing must_free to accept a NULL pointer? If we did this, I  
could just whack the pointer in the guardian and the rest of the GC  
process would proceed normally.

Is there any enthusiasm (for/against) in the user community for  
including mmap in libguile?

Regards,
        Dan Ridge