On Tue, 26 Jun 2001, Greg Marr wrote: > At 03:19 PM 06/26/2001, [EMAIL PROTECTED] 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. Thoughts? --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
