apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: [PATCH] mmap_setaside (with apr_mmap_dup)
Date Thu, 15 Nov 2001 06:50:52 GMT
On Wed, 14 Nov 2001, Brian Pane wrote:

> I gave up trying to do full reference counting semantics for
> duplicates of apr_mmap_t, because I couldn't find a suitable
> pool to own the locks that would be required in a threaded
> implementation.  Instead, apr_mmap_dup() lets the caller
> specify which of the two apr_mmap_t structs--the original one
> or the new one--is the owner of the mmap (and is responsible
> for destroying it).

Yeah, that could work.  I'l have to think on it a bit to see if I can come
up with any cases where it won't work, but it seems okay so far in
concept [haven't looked closely at the implementation yet].

> The patch includes a change to mod_file_cache to create a non-owner
> copy of the mmap for the bucket brigade to use, so that the mmap can't
> get unmapped by any code other than mod_file_cache itself

Why is that necessary?  The original mmap from mod_file_cache is owned by
mod_file_cache and is allocated out of cmd->pool.  cmd->pool definitely
lives longer than r->pool.  I guess the problem is that cmd->pool is not
an ancestor of r->pool, right?  It's disjoint (kind of a great-uncle or
something ;).  FEH.  Is there some clean way we can allocate the mmap out
of a better pool than the cmd->pool [like pchild or something]?  The less
work we do at request time, the better.  I guess this wouldn't be the end
of the world, though.


   Cliff Woolley
   Charlottesville, VA

View raw message