apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Sat, 14 Jul 2001 19:43:53 GMT
> > 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.  

Err, doesn't destruction of the mutex wake everyone up?
Oh, wait, does every process share the same mutex?

> And, destroying its parent pool does *NOT* destroy the thread.
> Look at the code again.  

Well, it should, although it may not do so now.

> 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

Could be I'm way off too.

Sander


Mime
View raw message