Andi Gutmans wrote:
> I just checked and it seems like Apache APR memory pools use mutex
> locking.
> It'd be better to use functions like the Win32 ones which don't use
> mutex locking (as we made sure that only one thread allocates from its
> pool). This could be achieved by compiling apr_pools.c without
> APR_HAS_THREADS but I bet the default Apache 2 build has this enabled.
> Any ideas?
> Andi
It's not as bad as it looks. :-)
The APR pools do locking only in a few situations:
* Creating a new pool
* Creating a subpool of a pool
* Destroying a pool
* Adding space to an existing pool, if it's used up its initial 8KB
allocation
So the simplest case, the lifetime of a pool looks like:
- create the pool, requiring a lock/unlock
- do hundreds of allocations from the pool, none of which require locking
- destroy the pool at the end of the request, requiring one
lock/unlock for
the entire thing
In general, that model works well: over the lifetime of a pool that
handles O(n) allocation operations, we only have to do O(1) lock/unlock
operations.
But there's an additional optimization that's possible: Sander Striker
added support for thread-specific allocators a while back. The per-request
pools in most of the Apache 2.0 MPMs take advantage of this. Each pool
has an "apr_allocator" object that supplies it with raw memory blocks.
These allocators can be designated as either thread-private or shared
across threads. And a thread-private allocator gets to skip the mutex
operations.
If you want to try the APR pools, the easiest approach might be to either
use the request_rec->pool directly or create a sub-pool from it.
--Brian
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
