On Thu, Sep 16, 2010 at 11:53:39AM +0200, Graham Leggett wrote:
> On 16 Sep 2010, at 9:13 AM, Ruediger Pluem wrote:
>
> >>+static apr_status_t file_cache_create(disk_cache_conf *conf,
> >>disk_cache_file_t *file,
> >>+ apr_pool_t *pool)
> >>+{
> >>+ file->pool = pool;
> >>+ file->tempfile = apr_pstrcat(pool, conf->cache_root,
> >>AP_TEMPFILE, NULL);
> >>+
> >>+ apr_pool_cleanup_register(pool, file,
> >>file_cache_temp_cleanup, file_cache_temp_cleanup);
> >
> >Is this correct? Do we want to call file_cache_temp_cleanup when
> >we get forked?
>
> I don't follow, when you we fork during normal request handling?
If using mod_cgi the INCLUDES filter can cause fork/exec when processing
an exec or include, so getting the child cleanups right for any filter
code certainly matters.
On this vein, to say:
> In theory the thread next door has no access to our r->pool,
isn't strictly correct; if apr_proc_create() were to be used in a
threaded process all child cleanups are run for all pools descendant
from the APR global pool, which may include other threads. But this
isn't done thread-safely and it would be huge a train wreck, hence
mod_cgid.
Regards, Joe
