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 Wed, 05 Feb 2003 20:35:22 GMT
At 09:11 AM 1/31/2003, Bill Stoddard wrote:

>>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.

>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.

I agree 100% - complexity increases bugs - barrier for entry (new users trying
to grok the schema) etc, etc.

Let's review those issues we can't dispell:

  * Both Win32 and Unix will register other_child processes.

  * Unix can discover any dying process from the 'process tree' - those
    created by this process.  Win32's handle on this issue is really poor
    (all puns intended.)  So Unix today and in the future will use the
    old apr_proc_other_child_read() (renamed to _died) to 'check' off
    that process.  It can return APR_SUCCESS if we have a 'hit' that
    the process is an other child, or APR_xxx status when we miss
    and other_child doesn't know about the given PID.

For this purpose, I'm proposing apr_proc_other_child_alert_one(),
passing the apr_proc_t, reason and status.  So we deprecate the
poorly named _read() flavor with:

/** @deprecated */
apr_status_t apr_proc_other_child_read(apr_proc_t *pid, int status)
{
    return apr_proc_other_child_alert_one(pid, APR_OC_REASON_DEATH, status);
}

Now we can send one of many alerts (reason) to the given OC maintainance
function :-)


  * Unix calls apr_proc_other_child_check() to warn everyone that we
    are shutting down, and we need to maintain the behavior (but not
    the very misleading function name.)  

  * Win32 needs a function to check the health of the processes without
    signaling them that we are restarting.

SO... I'm proposing apr_proc_other_child_refresh_all which will go through
the entire list, and send the desired reason code to all running processes'
maintenance functions.  So we deprecate the _check() fn with:

/** @deprecated */
void apr_proc_other_child_check(void)
{
    apr_proc_other_child_refresh_all(APR_OC_REASON_RESTART)
}

And we add a new reason to the maint callback for the health check
and then call apr_proc_other_child_refresh_all(APR_OC_REASON_CHECK)
for Win32's MPM.

Sound like a possible plan?

Bill  


Mime
View raw message