From: "Aaron Bannert" <[EMAIL PROTECTED]> 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.
