On Fri, Jul 13, 2001 at 04:57:05PM -0700, [EMAIL PROTECTED] 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
