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