If we're in backport season, I have a quick patch that I whipped up
yesterday to fix mod_disk_cache on 2.2.x on systems that have
APR_SENDFILE_ENABLED but EnableSendfile Off.

  Issac

William A. Rowe, Jr. wrote:
> [EMAIL PROTECTED] wrote:
>> Votes and Notes; the first four I would like to see applied before
>> tagging 1.2.4; add a better patch for the winnt mpm wait patch
>> that makes this reviewable (sometimes -U3 just isn't enough context.)
> 
> As Ruediger guessed and committed (thanks!) we are now two more patches down.
> 
> htcacheclean and httxt2dbm was a considerable flaw (considered that they
> didn't behave as documented, and these utilities are supposed to be easily
> moved around from box to box or run from a remote machine) and I'm about
> to commit that.
> 
> I see two final state bugs... I'm about to finish vetting niq's patch for
> listen reconfig which pegs httpd at 100% cpu
> 
>    * core: PR#37680
>      Fix NONBLOCK status of listening sockets on restart/graceful
>      http://svn.apache.org/viewvc?view=rev&revision=487901
>      +1: niq
> 
> someone please add a third voice on Nick's patch?  I'm guessing nobody
> bothered, next time http://issues.apache.org/bugzilla/show_bug.cgi?id=37680
> would help so the fruit hangs even lower.
> 
> The other fatal bug is:
> 
>>      * mpm_winnt: Fix return values from wait_for_many_objects.
>>          http://svn.apache.org/viewvc?view=rev&revision=428029
>>        2.2.x version of patch:
>>          Trunk version works
>> +        http://people.apache.org/~wrowe/mpm_winnt_waits.patch
>> +        is easier to read (-U8)
>>        +1: mturk, wrowe
> 
> Which i've created another, easier-to-read example of the backport, if you
> didn't follow the change last time please read the new patch and chime in
> a third +1?  You'll note it's simply a matter of unsetting errno before we
> invoke the wait, so we know if the 64th, 128th, etc are real errors or in
> fact indexes into the wait list array.
> 
> That's it.  I'd like to roll tonight so the vote can be closed by the 22nd.
> If another patch today fixes a runaway cpu or platform fault I might fix,
> if it's behavioral/optimization I won't be holding for it.  Those can go in
> the next 2 - 6 weeks whenever Jim rolls the release he's been aspiring to.
Index: modules/cache/mod_disk_cache.c
===================================================================
--- modules/cache/mod_disk_cache.c      (revision 488297)
+++ modules/cache/mod_disk_cache.c      (working copy)
@@ -359,6 +359,10 @@
     cache_info *info;
     disk_cache_object_t *dobj;
     int flags;
+#if APR_HAS_SENDFILE
+    core_dir_config *pdconf = ap_get_module_config(r->per_dir_config,
+                                                   &core_module);
+#endif 
 
     h->cache_obj = NULL;
 
@@ -453,7 +457,8 @@
     /* Open the data file */
     flags = APR_READ|APR_BINARY;
 #ifdef APR_SENDFILE_ENABLED
-    flags |= APR_SENDFILE_ENABLED;
+    flags |= ((pdconf->enable_sendfile == ENABLE_SENDFILE_OFF)
+             ? 0 : APR_SENDFILE_ENABLED);
 #endif
     rc = apr_file_open(&dobj->fd, dobj->datafile, flags, 0, r->pool);
     if (rc != APR_SUCCESS) {

Reply via email to