apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@ebuilt.com>
Subject Re: Threads and their Pools
Date Sat, 14 Jul 2001 01:18:15 GMT

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


Mime
View raw message