apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded
Date Tue, 17 Jul 2001 23:57:34 GMT
From: "Aaron Bannert" <aaron@ebuilt.com>
Sent: Tuesday, July 17, 2001 6:41 PM

> [snip]
> > > that would be registered in the "parent" thread's pool -- and would only
> > > be invoked by the "parent" thread.
> > > 
> > > pools let you do this, you don't need the mutexes for it, you just have to
> > > be explicit about parallelism.  (combine that with a root pool per thread
> > > and then we can remove alloc_mutex and free lists and push the real gnarly
> > > problems into the libc malloc where it's probably best solved.)
> > 
> > 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.
> It's probably just me, but I'm having trouble parsing this (I think I'm
> getting a cold :( ).
> Are you saying you want the thread function to have access to both a
> "scope" pool as well as an "allocator" pool, in case they are different?

I've officially graduated to the rbb (insert a decent name here) club :-)

Thank you, yes, scope pool defines teardowns such as cleanups, while the allocator
pool addresses our performance concerns :)

An obvious test is that 'allocator' is unique (e.g. thread private), a parent 
(at any depth) of the 'scope' pool, or the 'scope' pool itself.

View raw message