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