httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <mar...@beamartyr.net>
Subject Re: svn commit: r488780 - /httpd/httpd/branches/2.2.x/STATUS
Date Wed, 20 Dec 2006 08:10:50 GMT
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:
> wrowe@apache.org 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.

Mime
View raw message