apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: [PATCH] Re: mmap_setaside?
Date Wed, 14 Nov 2001 18:55:37 GMT
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




Mime
View raw message