> At 05:29 PM 3/4/2002, you wrote: > >On Mon, 4 Mar 2002, Bill Stoddard wrote: > > > > > Rather than an option to not register a cleanup, perhaps a function to > > > kill the cleanup would be more generally useful. > > > > > > apr_file_kill_cleanups(apr_file_t *file); > > > >You still have a problem with the apr_file_t disappearing when r->pool > >goes away, meaning you'd still need the apr_os_file_get/put thing, which > >just doesn't seem like a good idea to me. There has got to be a good way > >to do this... I'll keep thinking on it and get back to you asap. > > Caching introduces tons o' headaches. > > You won't like it, but you need a cross process cache pool derived from > process->pool.
Nahhh, don't need cross process squat. If you are interested in cross process caching, use mod_file_cache and preload the cache before the fork. I am completely not interested in generalizing mod_mem_cache to handle cross process caching at this point. > Individual cache entries should each gain a subpool of > their own ... if you do it right, the 'remove from cache' function is a cleanup > of that subpool. And perhaps this is a good direction to look in. I originally discarded the thought until Cliff pointed out the APR_XTHREAD breakage if we do not maintain an apr_file_t. The subpool must be exactly the size needed to hold the apr_file_t (and perhaps slightly larger). Today, the size of the subpool is way to large... Bill
