apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Tue, 17 Jul 2001 23:42:17 GMT
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

View raw message