On Fri, 13 Jul 2001, Aaron Bannert wrote: > 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: > > 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().) > > 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?
Semi-related to this is something I was wondering about this morning when I woke up, which is this: what happens if there's a per-thread allocator (sms) that's used as the parent of all sms's in that thread, and some portion of the code (maybe a module) running in that thread decides to spawn off some child threads? Clearly it cannot use the per-thread sms as the parent sms for the pools created in the child threads. Should it start over with an apr_sms_std as the parent sms for all sms's in the child thread? --Cliff -------------------------------------------------------------- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
