apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Altogether Broken OtherChild logic
Date Thu, 30 Jan 2003 23:39:13 GMT
At 04:47 PM 1/30/2003, Bill Stoddard wrote:

>>No, that is working fine.  It is whacking it because I modified the code in 
>>_check() to do exactly the same thing on Win32 as it does on Unix. 

>Humm... perhaps you got the cart before the horse...  if i recall correctly, I think I
created the _check function specificly to handle reliable piped logs on Windows.  Someone
(perhaps me I don't recall) dropped some code into the Unix branch to do the same thing. My
point... I think the unix side was broken and you made a mistake by assuming the unix side
was correct and modeling the windoes code after it.

And I very much agree of the 'correctness' of your original code [ :-) ]
But nice try...

Revision 1.24 / <otherchild.c?rev=1.24&content-type=text/vnd.htm>(view) - <otherchild.c?annotate=1.htm>annotate
- <otherchild.c?r1=1.htm>[select for diffs] , Thu May 17 12:20:01 2001 UTC (20 months,
2 weeks ago) by stoddard 
Branch: <otherchild.htm>MAIN 
CVS Tags: <otherchild.htm>APACHE_2_0_25, <otherchild.htm>APACHE_2_0_24, <otherchild.htm>APACHE_2_0_23,
<otherchild.htm>APACHE_2_0_22, <otherchild.htm>APACHE_2_0_21, <otherchild.htm>APACHE_2_0_20,
<otherchild.htm>APACHE_2_0_19, <otherchild.htm>APACHE_2_0_18 
Changes since 1.23: +39 -1 lines 
Diff to <otherchild.c.diff?r1=1.23&r2=1.htm>previous 1.23 (<otherchild.c.diff?r1=1.23&r2=1.htm>colored)

Add APR_HAS_OTHER_CHILD support to Win32

apr_proc_other_child_check() on Unix came first, afaict.

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.

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.


View raw message