On Tue, Jul 17, 2001 at 06:28:37PM -0500, William A. Rowe, Jr. wrote: > Yes, yes, yes. Can we please split the concept of a heirarchial parent (the > 'creator' thread's or process pool, in this case) from the allocation parent > (the actual give me memory for my pool from ... here!) Then we have an > "OS Knows Best" malloc/free mpm for threading, just as you suggest. > > This solves your thread-specific requirements and our scoping issues, along > with fixing the 'walk the chain of pools for a block' problem, both at once.
Okay, I will try and commit something into the SMS code that does this. If I understand you, there will be one parent which will handle allocation and another that will handle cleanups. This should handle your concerns about a thread that didn't exit properly and my concern about having a unnecessary locking in the allocation code. Deal? I'll make it default to having both parents be identical, and the apr_thread_create call can set it to be null (or a std. SMS). The only problem is the SMS code is chock-full of subtle race conditions right now. We *really* need more eyes on this code. -- justin
