On Wed, Jul 18, 2001 at 11:02:27AM -0500, William A. Rowe, Jr. wrote: > > And enforcing that the 'allocation' pool is either top-level itself, or a > > descendant of the 'scope' pool, assures that the cleanups will unwind > > properly for both (since this thread-child pool is torn down, everything > > below > > in the 'scope' heirarchy will be cleaned up, as well). > > Err... "enforce that the 'allocation' pool is either top-level itself, or the > same as or one of the parents of the 'scope' pool".
Yes. The trick, as I see it, is that we let the apr_thread_create function determine what the apr_thread_t's SMS is. If the thread_create function says the allocation SMS is now a "top-level" one or whether it uses the pool passed in. BTW, I'm not sure that the apr_pool_cleanup_for_exec will do the right thing in the SMS architecture because there is no common parent anymore. We may need to rethink how that function works. Thoughts? Of course, everyone realizes that in order to do all of this, we have to get SMS working. -- justin
