apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: cvs commit: apr-util/buckets apr_buckets_mmap.c
Date Wed, 27 Jun 2001 14:24:49 GMT
On Tue, 26 Jun 2001, Greg Marr wrote:

> At 03:19 PM 06/26/2001, rbb@covalent.net wrote:
> >No.  You can't allocate the MMAP out of malloc.  One of the goals of
> >pools is that they allow us to call malloc as little as
> >possible.  The MMAP should just get a copy of the filename, and this
> >problem goes away.
> You'd rather allocate and copy a string and then recreate an MMAP
> than call apr_malloc once?  If so, then there's something seriously
> wrong with apr_malloc.
> >You need to separate MMAPs from buckets.  Buckets are one place
> >MMAPs are used, but they are used in other places.
> How is adding reference counting to the MMAP type tying MMAPs to
> buckets?  They're totally unrelated, except that the bucket is going
> to use the MMAP.  There's no coupling the other way.

Okay, I took a break last night to think about all this whilst I was in
the car on my way to DC.  I came up with a few alternatives to the
refcounting idea (I'm starting to think that that could get really messy
really easily).  They all let the buckets code handle the problem instead
of putting any extra complexity into the APR mmap code.  I figured I'd
just throw them out here and let you all pounce on them.

(1) Go with Ryan's idea of reopening the file into the right pool and
morphing the MMAP.  But (and maybe this was his intention all along and I
just missed it), mitigate the need for this operation by limiting it to
only being used in cases where the pool requested for setaside is disjoint
from the current MMAP's pool (ie, when neither is an ancestor of the
other).  If the current pool is an ancestor of the requested pool, we just
return success (as is already done); if the requested pool is an ancestor
of the current pool, we deregister the cleanup from the current pool and
register it in the ancestor (requested) pool and copy the apr_mmap_t into
that pool.  This should make the reopening thing so infrequent as to be
possibly never even executed... can anyone think of a reason you'd ever
setaside into a disjoint pool?  That brings me to number two, which is:

(2) Change the rules for _setaside() to state that you can only setaside
into a parent or child pool, not a disjoint one.  I don't think this would
be too much of a burden on the caller, because I can't think of any
situation where someone would actually try to do that anyway.  The benefit
of this restriction is that it lets us get rid of what would be an extra
call to apr_pool_is_ancestor() in solution #1.

(3) Add a parameter to the _file_create() and _mmap_create() functions
that indicates whether the buckets code "owns" the apr_file_t/apr_mmap_t
function or not.  If it does, then the pool cleanup is deregistered as
soon as the bucket gets created.  Only when the very last reference to
that file/mmap bucket is being _destroy()'ed do you reregister it into the
appropriate pool (thereby deferring the file close/mmap delete, but
deferring it to the "right time", which should be faster than actually
stopping to close the file/delete the mmap during request processing when
the last referencing bucket is destroyed).  If the buckets code does not
"own" the resource, then the caller is guaranteeing the buckets code that
no matter how long the buckets referring to that resource stay around, the
resource will not disappear out from under them.  mod_file_cache could
make such a guarantee, for example.



   Cliff Woolley
   Charlottesville, VA

View raw message