httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: svn commit: r997545 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h modules/cache/mod_cache.c modules/cache/mod_cache.h modules/cache/mod_disk_cache.c modules/cache/mod_disk_cache.h
Date Fri, 17 Sep 2010 12:35:39 GMT
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

Mime
View raw message