httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: idle server processes not going away
Date Fri, 01 Jun 2001 19:18:50 GMT

> > As for the problem that Jeff is describing, this is a problem with trying
> > to make the old Apache 1.3 code fit the MPM model without paying enough
> > attention to the flow of the code.  Take a look at the 1.3 code, it uses
> > longjmp to make sure it is always executing the correct code.  The 2.0
> > code tries to use return codes from APR functions.  But, the basic code
> > still looks like the 1.3 code.  A few months ago, child processes were
> > morphing into parent processes when we tried to kill them off.  To fix
> > this, I modified some of the code to exit at the right time.  I believe
> > about a month later, Paul Reder made a similar change.  IMNSHO, this can
> > be solved only by actually taking the time to trace through the prefork
> > MPM, and figure out what is happening, and fixing the bugs.  BTW, the
> > threaded and perchild MPMs are incredibly similar to the prefork MPM in
> > this respect.
>
> I'm not sure what you mean by "fixing the bugs."
>
> As I see it, prefork wants to use signals as the way to tell child
> processes to go away.  Doing much in the signal handler is
> problematic.  Instead we need to 1) longjmp() from the signal handler to
> a safe spot and exit from there or 2) we make sure we wake up when the
> signal handler returns.  Do you have a third suggestion?
>
> I'll post a patch in the next few minutes for solution 2.  It seems to
> work fine.

I think the only way to really solve this, is to look at how the longjmp()
was used in 1.3 to ensure we died correctly.  I would also suggest looking
at how threaded dies.  If the real problem is the signal handling, then I
would suggest that Dean was correct about signals and daemons, and we
should just remove all singals and use the pipe_of_death for all Unix
MPMs.

Assuming that locks are interuptable is not a good idea IMHO.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------




Mime
View raw message