Cliff Woolley wrote:
[...]

I think the ideal situation would be if we had an apr_mmap_dup() similar
to our apr_file_dup().  apr_file_dup() already solves this problem for
files by ensuring that a duplicate copy of the file descriptor lives as
long as the given pool.  apr_mmap_dup() in the case of duping into an
ancestor pool could do exactly what we're trying to get mmap_setaside() to
do: copy the apr_mmap_t() into the ancestor pool and tweak the cleanups.
In the case of disjoint pools, it could do something else (what I haven't
decided yet).  Then mmap_setaside() becomes as easy as file_setaside() is.

Thoughts?


apr_mmap_dup() with an optimization for the ancestor-pool case sounds good to me. Actually, with a slight modification, I think this can handle the non-ancestor-pool case too: * Create a reference count, in storage outside of any pool. (I have no major reservations about doing a malloc for this, since it's quick compared to the mmap itself. If it ever became a bottleneck, we could add a custom free list.) * Set the reference count to 1 when it's created, and increment in apr_mmap_dup(). * In mmap_cleanup(), decrement the reference count. If it's now zero, munmap, and free the struct that holds the reference count. If the reference count is nonzero, do nothing.

What do you think?

Thanks,
--Brian





Reply via email to