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 that. Ryan _____________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] -----------------------------------------------------------------------------
