Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Thu, 16 Sep 2010 12:02:38 +0200
Message-ID: 
 <99EA83DCDE961346AFA9B5EC33FEC08B04AE30A6@VF-MBX11.internal.vodafone.com>
In-Reply-To: <4529AE1A-4FC1-46F0-A419-570170077827@sharp.fm>
Thread-Topic: 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
Thread-Index: ActVhSLVPdm27IyVRg+Shpoqz38oQQAACtQg
References: <20100916000515.2AD9F23888CF@eris.apache.org>
 <4C91C3B1.5060601@apache.org> <4529AE1A-4FC1-46F0-A419-570170077827@sharp.fm>
From: =?iso-8859-1?Q?=22Pl=FCm=2C_R=FCdiger=2C_VF-Group=22?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>

=20

> -----Original Message-----
> From: Graham Leggett =20
> Sent: Donnerstag, 16. September 2010 11:54
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r997545 - in /httpd/httpd/trunk:=20
> CHANGES include/ap_mmn.h modules/cache/mod_cache.c=20
> modules/cache/mod_cache.h modules/cache/mod_disk_cache.c=20
> modules/cache/mod_disk_cache.h
>=20
> On 16 Sep 2010, at 9:13 AM, Ruediger Pluem wrote:
>=20
> >> +static apr_status_t file_cache_create(disk_cache_conf *conf, =20
> >> disk_cache_file_t *file,
> >> +                                      apr_pool_t *pool)
> >> +{
> >> +    file->pool =3D pool;
> >> +    file->tempfile =3D apr_pstrcat(pool, conf->cache_root, =20
> >> AP_TEMPFILE, NULL);
> >> +
> >> +    apr_pool_cleanup_register(pool, file,=20
> file_cache_temp_cleanup, =20
> >> file_cache_temp_cleanup);
> >
> > Is this correct? Do we want to call file_cache_temp_cleanup=20
> when we =20
> > get forked?
>=20
> I don't follow, when you we fork during normal request handling?
>=20
> This function creates the structure that keeps track of each of the =20
> three files we write, along with the tempfiles used to construct the =20
> data. The cleanup guarantees that tempfiles are deleted should the =20
> request end unexpectedly, and that we don't leave temp files lying =20
> around as we previously did.

Hm. What happens in a threaded MPM, where we a doing a caching operation
and another thread causes a fork (e.g. because of mod_cgi (I know
should not be used with threaded MPM's), or some 3rd party module that
does a fork). Wouldn't that cause our cache file to be deleted in the
middle of the caching?
My comment is only about the 4th parameter to apr_pool_cleanup_register
set to file_cache_temp_cleanup, I am fine with setting the 3rd to
file_cache_temp_cleanup and fully follow that purpose.
Shouldn't we set the 4th paramter just to apr_pool_cleanup_null?


Regards

R=FCdiger