[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-dev
Subject:    Re: Altogether Broken OtherChild logic
From:       Bill Stoddard <bill () wstoddard ! com>
Date:       2003-01-31 15:11:34
[Download RAW message or body]

So I 've actually spent some time looking at this...

>apr_proc_other_child_check() on Unix came first, afaict.
>
Right you are.

>Now we're left with ery simple problem.  OC works on Unix today, and 
>it's broken on Win32.  Unix's logic is well exercised by a larger group,
>WinNT's by a much smaller minority.  I trust their logic, but the names
>don't match up.
>
>I'm just going to try to wire it all back together such that Unix (working) 
>stays working, and Win32 is fixed for 2.0.45 within the next few days.
>
>Yes - it's bogus they called a fn apr_proc_other_child_check() as 
>*THE* restart signal.  But renaming that fn now is probably safer.
>
I agree.

>As for your question about polling, if we cycle every second we waste
>cpu - if we sample every few seconds we lose more log entries etc.
>If we receive alerts when the otherchild processes die we can react
>immediately without the extra loops.
>
>Bill
>
In principle I agree but I am not sure the extra complexity of your 
proposed solution is worthwhile for implementing reliable piped logs.  I 
really hate complex solutions to simple problems.  Complexity makes the 
code more difficult to debug and maintain and raises the entry barrier 
for new folks interested in joining the project.   I often hear the 
argument for a complex solution in favor of a simpler solution because 
the complex solution "might be useful for other applications" or is 
"more extensible", etc.  This is a good line of argument and is quite 
often true, but not always.  It -is- possible to over engineer (biggie 
size :-) software.  I'll happily review whatever you come up with, so 
party on dude.

Bill

[prev in list] [next in list] [prev in thread] [next in thread]