apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: Pools rewrite [2]
Date Tue, 11 Dec 2001 15:10:11 GMT
On Tue, Dec 11, 2001 at 11:27:25AM +0100, Sander Striker wrote:
> A thread doesn't own any pools nor does it know about specific pools,
> the same goes for the other way around.

Actually, there is a pool created and associated to a thread when that
thread is created. See APR_POOL_IMPLEMENT_ACCESSOR_X in thread.c.

> The idea is to have to option to optimize for the situation where
> you _know_ that a pool will only be accessed by one thread at a time.

Back in June or July I advocated removing the thread's pool from the
actual thread structure, and just letting the app pass whatever pool
contexts they needed through the opaque thread data, but that didn't
happen.  So now I'd expect someone who wanted to use a special allocator
to first call the accessor (apr_thread_pool_get(thd) implemented with
APR_POOL_IMPLEMENT_ACCESSOR) and then create another subpool that has
private free lists and no global locks.

> The app is in control.  If you're not sure if you are using a pool
> in more than one thread at a time, don't disable locking for that
> pools allocator.

Absolutely. :)


View raw message