apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: Altogether Broken OtherChild logic
Date Thu, 30 Jan 2003 22:22:34 GMT
William A. Rowe, Jr. wrote:

>At 02:03 PM 1/30/2003, Jeff Trawick wrote:
>  
>
>>wrowe wrote:
>>
>>    
>>
>>>>Finally, it looks like apr_proc_other_child_read is the function we
>>>>*really* wanted
>>>>to use within the health check.  But it seems all of these
>>>>apr_proc_other_child
>>>>functions are really misdocumented within APR.  Would someone step up and
>>>>spell out exactly what they are *supposed* to be doing within unix,
>>>>and then we
>>>>can discuss how to make them portable to Win32?
>>>>        
>>>>
>>apr_proc_other_child_read() is called when the monitor (e.g., MPM) knows that a process
has died; it passes the apr_proc_t describing the dead process to apr_proc_other_child_read(),
and if that dead process was a registered "other child", then the maintenance function for
that other child is called with APR_OC_REASON_DEATH
>>    
>>
>
>Good, we agree on what this function is doing.
>
>  
>
>>sounds pretty hokey to me; maybe apr_proc_wait() could call the maintenance function
automatically if a newly-deceased process was registered as "other child"
>>    
>>
>
>I'm simply thinking of renaming it apr_proc_other_child_died() and documenting
>it correctly.  Step two is determining how I can then identify and report that
>case in the WinNT MPM, or automagically as a callback.
>  
>
What's wrong with MPMs polling OCs?  Simple, efficient, effective and 
has served httpd 1.3 well.  Let's not biggie size. I -hate- biggie size 
when a simpler solution is just as effective.

Bill



Mime
View raw message