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:15:00 GMT
On Fri, Jul 13, 2001 at 04:57:05PM -0700, rbb@covalent.net wrote:
> 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.

This is where I disagree, but only slightly:

APR threads should be *using* a sub-pool on all platforms. I believe it
should be the responsibility of the caller to define the lifetime
of that thread and it's data, not the thread itself.

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

That is a neat trick, but it causes all applications that wish to
use portable threads in APR to take on the processing bulk of child
pools. What happened to "lightweight" threads? ;)

I still think the subpool could be created outside of apr_thread_create,
and passed in. This works well with the new SMS code, so threads that
are created for specific purposes could be paired up with a particular

> > 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
> that.

But why must threads be involved in subpool creation? Threads do have a
lifetime, and therefore it makes sense to pass them a pool for that purpose,
but I don't see how threads need to be dictating other pools.


View raw message