You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@raleigh.ibm.com> on 1999/11/11 16:56:04 UTC

Moving reliable piped logs into APR

This may be a stupid idea, but I want to get some opinions anyway.  Would
anybody have a problem moving the reliable piped logs logic into APR?  We
would obviously call it something else, but it is REALLY useful logic to
have available to us, and I can see other programs needing similar logic.

Ryan

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


Re: Moving reliable piped logs into APR

Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Nov 12, 1999 at 09:19:02AM -0500, Ryan Bloom wrote:
> 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.

ap_{register,unregister}_other_child, probe_writable_fds, and
reap_other_child?

This is a personal taste decision, but I think that it's really too
high-level to be thrown into APR.

I do think it should be shared code though. I don't know if it can be
put into src/main, but I see no reason that the Unix MPMs can't share
it.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/

Re: Moving reliable piped logs into APR

Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
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.	


Re: Moving reliable piped logs into APR

Posted by Greg Stein <gs...@lyra.org>.
On Thu, 11 Nov 1999, Manoj Kasichainula wrote:
> I don't think APR should get in the business of making policy
> decisions.

+1 on Manoj's view.

--
Greg Stein, http://www.lyra.org/


Re: Moving reliable piped logs into APR

Posted by Manoj Kasichainula <ma...@io.com>.
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/

Re: Moving reliable piped logs into APR

Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I agree that the application needs full control of WHEN it's done, but why
does the application need control of HOW it's done?  

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.

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?

Ryan

On Thu, 11 Nov 1999, Bill Stoddard wrote:

> I'd prefer not. This is very application specific function, IMO, and the
> application needs to have FULL control over when and how its done.
> 
> Bill
> ----- Original Message -----
> From: Ryan Bloom <rb...@raleigh.ibm.com>
> To: <ne...@apache.org>
> Sent: Thursday, November 11, 1999 10:56 AM
> Subject: Moving reliable piped logs into APR
> 
> 
> >
> > This may be a stupid idea, but I want to get some opinions anyway.  Would
> > anybody have a problem moving the reliable piped logs logic into APR?  We
> > would obviously call it something else, but it is REALLY useful logic to
> > have available to us, and I can see other programs needing similar logic.
> >
> > Ryan
> >
> > _______________________________________________________________________
> > 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.
> >
> 

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




Re: Moving reliable piped logs into APR

Posted by Bill Stoddard <st...@raleigh.ibm.com>.
I'd prefer not. This is very application specific function, IMO, and the
application needs to have FULL control over when and how its done.

Bill
----- Original Message -----
From: Ryan Bloom <rb...@raleigh.ibm.com>
To: <ne...@apache.org>
Sent: Thursday, November 11, 1999 10:56 AM
Subject: Moving reliable piped logs into APR


>
> This may be a stupid idea, but I want to get some opinions anyway.  Would
> anybody have a problem moving the reliable piped logs logic into APR?  We
> would obviously call it something else, but it is REALLY useful logic to
> have available to us, and I can see other programs needing similar logic.
>
> Ryan
>
> _______________________________________________________________________
> 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.
>