> > 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?
Hmm, good question. Maybe it could use the sms's parent? Although that would depend on what the parent was whether that was clever. This is something else that needs looking into... BTW, what in hells name were you doing thinking about this as you woke up??? :) david
