httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: apr_file_open() and caching file descriptors
Date Tue, 05 Mar 2002 13:56:41 GMT

> 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


Mime
View raw message