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 2] Re: [PATCH] mmap_setaside (with apr_mmap_dup)
Date Fri, 16 Nov 2001 23:25:26 GMT
On Fri, 16 Nov 2001, Greg Stein wrote:

> > around the reference count. The lock API requires that we create the
> > lock from a pool, but there isn't a really suitable pool from which
> > to allocate the lock, given that its lifetime isn't necessarily tied
> > to that of a request or connection.
> The "suitable pool" is that of the apr_mmap_t itself. Note that the file
> cache would be putting that lock into its own long-lived pool.
> Not so hard, or I'm missing something :-)

You're missing something.  :-)

Let's say you have a pool hierarchy like this:

    / \
   b   c

You have an apr_mmap_t allocated out of c.  You request to dup the mmap
into b.  Will b live longer than c?  No way to know.  Will c live longer
than b?  No way to know.  So if you've allocated your refcount or the lock
on that refcount out of c, and c goes away before b does, then b has a
reference to no-longer-existing memory.

This is not an odd situation: it's almost exactly what's happening in
mod_file_cache right now.  c is the cmd->pool.  b is the c->pool.  d is
the r->pool.  (There might be some pools between a and b for the diagram
to be exactly right, but the hierarchy is essentially correct I believe.)
Granted, in that particular example, c lives much, much longer than b, but
in general that's not at all guaranteed to be the case.


   Cliff Woolley
   Charlottesville, VA

View raw message