On Sat, 14 Jul 2001, Aaron Bannert wrote:
> On Sat, Jul 14, 2001 at 12:27:05PM -0700, Justin Erenkrantz wrote:
> > 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.
>
> Here's what my box's pthread_cancel man page says:
>
> Cancellation points are those points in the program execu�
> tion where a test for pending cancellation requests is
> performed and cancellation is executed if positive. The
> following POSIX threads functions are cancellation points:
>
> pthread_join(3)
> pthread_cond_wait(3)
> pthread_cond_timedwait(3)
> pthread_testcancel(3)
> sem_wait(3)
> sigwait(3)
>
> Doesn't pthread_mutex_acquire sit in sem_wait() or sigwait()? That'll
> let it be cancel()ed.
>
>
> Anyway, yes the pool cleanup routines that are supposed to be calling
> apr_thread_exit() are broken because nothing in httpd is calling
> apr_thread_exit() (AFA-my-grep-says). So let's either let the thread
> creator (aka httpd) do the cleanup registration, or put it in apr
> (as an optional feature).
Async cancellation of threads is VERY bad ju-ju. We don't do it because
it causes most, if not all, thread libraries to leak. The cleanups are
called because the child pool is destroyed when all the threads die.
Ryan
_____________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
-----------------------------------------------------------------------------
