Just for a little insight, this was promted while trying to sort through the apr_thread_* API for use in "flood", the httpd-tester Justin and I have been working on.
I was curious why apr_thread_exit() needed the apr_thread_t that it is supposed to exit, since that is not typically something a thread has direct access to. Then I realized that it was simply destroying the pool that is a part of that apr_thread_t structure, and I became suspicious. I still don't see how a thread can call apr_thread_exit() for itself, and I don't see any examples anywhere in httpd-2.0 or apr[-util]. -aaron On Fri, Jul 13, 2001 at 04:13:30PM -0700, Aaron Bannert wrote: > It appears to me that APR threads (on unix) are automatically creating a > subpool, and then later destroying it only if/when apr_thread_exit() is > explicitly called. I have a few questions about threadproc/unix/thread.c: > > 1) How do we guarantee the child-pool is being destroyed? What happens > if the thread just exits? > (I don't see anywhere in httpd that is calling apr_thread_exit().) > > 2) Why are we forcing applications using APR's threads to use pools > in the first place? Even if we require some sort of allocator to get > memory from for the thread structures themselves, why are we forcing > them to be child-pools? > > -aaron
