On Wed, 14 Nov 2001, Brian Pane wrote:
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
Cliff Woolley wrote:
On Sat, 10 Nov 2001, Brian Pane wrote:
Is anybody working on modifying mmap_setaside so that it doesn't
have to memcpy the file contents? (I recall this being an issue
a while ago.) This could yield a small but measurable improvement
on requests that aren't handled using
Cliff Woolley wrote:
On Tue, 13 Nov 2001, Brian Pane wrote:
Thanks for the pointer. Here's my attempt to work around the problem
that you noted in that message--the fact that the apr_mmap_t cleanup
function isn't accessible from within mmap_setaside. My solution was
to add a pointer to the
On Wed, 14 Nov 2001, Brian Pane wrote:
Actually, the more I think about it, the less I like the idea of
exposing mmap_cleanup in any form (including the function pointer
in the struct). The problem is that it introduces extra coupling
between the mmap code and the bucket code, so that the
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
