Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030131112822.03983b30@pop3.rowe-clan.net>
Date: Wed, 05 Feb 2003 14:35:22 -0600
To: Bill Stoddard <bill@wstoddard.com>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: Altogether Broken OtherChild logic
Cc: dev@httpd.apache.org, dev@apr.apache.org
In-Reply-To: <3E3A9226.40702@wstoddard.com>
References: <5.2.0.9.2.20030130171012.03bc6b10@pop3.rowe-clan.net>
 <5.2.0.9.2.20030130144909.02c4edf0@pop3.rowe-clan.net>
 <5.2.0.9.2.20030124110322.03045588@pop3.rowe-clan.net>
 <5.2.0.9.2.20030124110322.03045588@pop3.rowe-clan.net>
 <5.2.0.9.2.20030130144909.02c4edf0@pop3.rowe-clan.net>
 <5.2.0.9.2.20030130171012.03bc6b10@pop3.rowe-clan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

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