httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: multithreaded pools?
Date Tue, 10 Jul 2001 15:12:51 GMT
On Tue, 10 Jul 2001, dean gaudet wrote:

> On Sun, 8 Jul 2001, Roy T. Fielding wrote:
> [clean_child_exit]
> >
> > It is only called when the child exits and not per-thread.  I think the
> > threads are already dead by that point, or locked-up due to some fatal
> > error that is the reason why clean_child_exit is being called.
> when you say "the threads are dead" you're referring to the httpd threads.
> there could be zillions of other threads started up by third party
> modules, still running.
> but also, if you look at the call sites within threaded.c you'll find that
> even the httpd threads are (potentially) still running.
> huh, at least one of the call sites -- where apr_thread_create fails looks
> like a genuine bug.  exit the PROCESS if you can't create a thread, for
> any reason whatsoever?  this is in start_threads.
> also, clean_child_exit is called when SIGTERM is received... and makes no
> attempt to stop the httpd threads.

I know it looks like that when you first look through the code, but
receiving a SIGTERM should not execute clean_child_exit.  We have a single
thread in sigwait, which means that all signals should be blocked in all
other threades.  The one sigwait thread then gets the signal, and waits
for all the threads to die before it calls clean_child_exit.

Now, having reviewed the code, this looks broken, because we are setting a
signal handler, and I don't see us blocking the signals anywhere, but that
was the design anyway.  :-(

> so basically clean_child_exit() really should just call exit() and avoid
> the possibility of damaging data by calling cleanups owned by other
> threads (and with no locking to protect them).


Ryan Bloom               
Covalent Technologies

View raw message