Re: svn commit: r1004753 - /httpd/httpd/branches/2.2.x/STATUS

2010-10-09 Thread Jeff Trawick
On Thu, Oct 7, 2010 at 6:03 AM, Joe Orton jor...@redhat.com wrote:
 On Thu, Oct 07, 2010 at 10:50:48AM +0100, Joe Orton wrote:
 I've no strong objection to this but it deserves a comment in the code
 describing why that apr_pool_clear call is redundant; a thorough

 ^NOT redundant


on my list for today


Re: svn commit: r1004753 - /httpd/httpd/branches/2.2.x/STATUS

2010-10-07 Thread Joe Orton
Response as requested ;)

On Tue, Oct 05, 2010 at 06:16:14PM -, William Rowe wrote:
 --- httpd/httpd/branches/2.2.x/STATUS (original)
 +++ httpd/httpd/branches/2.2.x/STATUS Tue Oct  5 18:16:14 2010
 @@ -177,11 +177,14 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
  PR: 43857
  Trunk patch: http://svn.apache.org/viewvc?rev=943650view=rev
  2.2.x patch: Trunk patch works
 -(on hold) +1: trawick, rjung
 +(on hold) +1: trawick, rjung, wrowe
  jorton points out that the problem symptom was probably the reslist
  issue, which may have a better fix; also, this change could hide 
  other problems:
http://www.mail-archive.com/d...@apr.apache.org/msg23090.html
 +wrowe adds that the pre_cleanup registration is not in apr-util 1.3, it 
 was
 +never backported, and that if this patch works, it's probably the best 
 solve
 +for legacy 2.2.

I've no strong objection to this but it deserves a comment in the code 
describing why that apr_pool_clear call is redundant; a thorough 
reviewer would remove it since it *should* be redundant, reslist pool 
usage fubars notwithstanding.  Also in CHANGES it should be described 
specifically as a workaround for the described symptoms in the PR,

Run cleanups for final request when process exits gracefully.

is something that happens already... e.g.

  prefork: Fix possible crashes on child exit in APR reslist 
  cleanup code.  PR: blah blah

Regards, Joe


Re: svn commit: r1004753 - /httpd/httpd/branches/2.2.x/STATUS

2010-10-07 Thread Joe Orton
On Thu, Oct 07, 2010 at 10:50:48AM +0100, Joe Orton wrote:
 I've no strong objection to this but it deserves a comment in the code 
 describing why that apr_pool_clear call is redundant; a thorough 

^NOT redundant