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).
-aaron
