On Sat, Jul 14, 2001 at 09:13:08PM +0200, Sander Striker wrote:
> The way I see it, each process has a single pool instance as the parent
> for all the threads. Resetting or destroying that pool should effectively
> kill all threads. What am I missing?
As I see it, the problem is:
[ Platforms with SAFE_ACCEPT == APR_SUCCESS rather than the lock don't
apply here. ]
All threads are stuck in the accept mutex except for one. It reads the
POD. And, it is time to die. It sets workers_may_exit to 1. It then
releases the accept mutex and exits. Another *child process* acquires
the accept mutex. Depending upon how many child processes you have, it
may take a while for all of the threads in the doomed child process to
acquire the mutex, wake up, check workers_may_exit, release the mutex,
and then exit. Only when all of the threads in the doomed child process
are exited does any cleanup occur.
These sibling threads are blocked until they receive the mutex. They
aren't going to be going anywhere until the mutex is turned over to
them. They can't check the value of workers_may_exit *until* they
acquire the mutex. Condition variables help *somewhat*, but the
problem is now of scope - you have an interprocess condition and a
intraprocess condition to check. Does this work? I don't know.
And, you can't kick the thread out of the mutex acquire (pthread_cancel
or similar strategies don't cancel a mutex operation), so you are
screwed. And, destroying its parent pool does *NOT* destroy the
thread. Look at the code again. The only person that can call
pthread_exit() is the actual thread itself. You can't call
pthread_exit on behalf of another thread (i.e. from the thread that
knows it is doomed or a cleanup thread). It just doesn't work like
that.
I just don't agree with Ryan's assessment here. But, it's possible
I'm missing some major piece of code. -- justin
