apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: Threads and their Pools
Date Fri, 13 Jul 2001 23:57:05 GMT

Okay, there are some naming conventions in this e-mail that make it very
hard to determine what you are talking about.  There are thread pools and
child pools, they are not the same thing.  A child pool is associated with
a child process, a thread poo is associated with a thread.

> 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:

APR threads should be allocating a sub-pool on all platforms.

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

The thread pool is destroyed in one of two cases, when the thread kills
itself using apr_thread_exit, or when the parent pool is cleaned.  The
reason a separate thread pool is created, is because that allows the
thread to register a cleanup with it's own pool.  That way, when the pool
goes away, so does the thread, automagically.  At least, that was how it
used to work.  I do not see the cleanup being registered right now.  :-(

> 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?

ALL APR functions use pools.  Ben (either Laurie or Hyde, I can't remember
which) outlined why we do this sort of thing back when APR was first
written.  I would need to review the archives to give a better answer than


Ryan Bloom                        	rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message