httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@raleigh.ibm.com>
Subject Re: Moving reliable piped logs into APR
Date Fri, 12 Nov 1999 14:19:02 GMT

I think the problem is I said reliable piped logs when I meant other
child.  I knew what I meant, but I am assuming nobody else did, and that's
why this seemed like a reasonable request to me, but not to anybody else.
My bad.  :-)

All I want to do, is move the register_other_child code and the two or
three other functions associated with it down to APR.  The reliable piped
logging code itself would stay where it is.

I will apologize profusely now for not thinking through what I said.  It
made such sense to me, I couldn't understand why everybody was complaining
about policy decisions.  I feel like a bone head.

OK, so does anybody have a problem with moving the OTHER_CHILD code down
to APR?

Ryan

On Thu, 11 Nov 1999, Manoj Kasichainula wrote:

> On Thu, Nov 11, 1999 at 11:24:51AM -0500, Ryan Bloom wrote:
> > I just want to move the logic that allows us to register a sub-process as
> > an important process.  I am not suggesting that any of this is used in APR
> > calls.
> 
> ap_note_subprocess is already in APR. I guess you're talking about the
> code to restart a process when it dies?
> 
> > Moving this logic down to APR doesn't have any influence of when it's
> > used.  Could you explain why you think the application needs to have
> > control of how it's implemented?
> 
> Because the decision about when to restart a logging process and when
> to give up on it is an application-level decision. If a piped logger
> dies 3 times after only staying alive 1 second, do we bother to
> restart it again? Maybe 5 segfaults is the right number to give up at.
> Do certain types of death mean our behavior will change? SIGTERM
> probably should always result in the process starting again, because
> that's what the admin wanted. This might not be true for SIGSEGV.
> 
> I don't think APR should get in the business of making policy
> decisions.
> 
> -- 
> Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
> 

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	


Mime
View raw message