[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?
-aaron
