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



Reply via email to