From: <[EMAIL PROTECTED]>
Sent: Tuesday, July 17, 2001 11:13 AM
>
> I believe that the problem is that the threaded code is creating the
> pool, and not advertising it to the thread itself. This is an easy thing
> to fix. I do not agree that every APR app that uses threads should have
> to create their own thread pools. That is wasted effort by every APR app.
>
> I would like to see a conclusion to this thread quickly. So, could people
> please post their desires quickly, and what they want to see from this.
thread-local pools would be a nice improvement, perhaps as an argument to
apr_thread_create. They can be flagged such that they avoid locking their own
own allocations (of course their 'parent' allocator, malloc, or the parent
free-list management, may still need to lock based on platform and so forth).
But _unless_ they remain rooted to the top level pool, in apr_process_create
they become orphaned, and their cleanups are never executed. That isn't workable.
It sounds like (forgive me if I'm stating the obvious) that a pool needs two
kinds of parent sms pools. One is the 'heirarchy' for purposes of setup and
teardown. The other is the 'allocator', where the blocks will be allocated from.
Want to use the conventional 1.3 model? The heirarchial parent is the parent pool,
but the allocatation parent is the single top level pool.
Want to flip to a malloc, that trusts the clib to 'do the right thing'(sm) with
cpu/thread specific free lists? Then we build a very simple malloc/free sms that
can be passed as the allocation parent when the pool is created.
If I've abused the sms concept here, then correct me, but I don't see any issues
remaining beyond semantics and syntax.
Bill
