You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Reid <dr...@jetnet.co.uk> on 2001/05/17 18:03:29 UTC
Pools & locking?
Did we ever do anything about the locking issue that Justin (ISTR) threw up
when we build apr using threads? ISTR some emails but wasn't sure we ever
actually fixed it, hence the question...
david
Re: Pools & locking?
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Thu, May 17, 2001 at 05:03:29PM +0100, David Reid wrote:
> Did we ever do anything about the locking issue that Justin (ISTR) threw up
> when we build apr using threads? ISTR some emails but wasn't sure we ever
> actually fixed it, hence the question...
Not yet. The fix is to remove the locking code from within the pools,
though it might be better to get hierarchical memory allocators working
first so that we can have separate per-thread allocators versus the
single global allocator we have now.
....Roy
Re: Pools & locking?
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, May 17, 2001 at 05:03:29PM +0100, David Reid wrote:
> Did we ever do anything about the locking issue that Justin (ISTR) threw up
> when we build apr using threads? ISTR some emails but wasn't sure we ever
> actually fixed it, hence the question...
Basically, Roy pointed out that we are attempting to lock pools that are
inherently only part of a request (and only part of one thread). So, if
APR_HAS_THREADS is enabled, each allocation from the request_rec pool
will (for all but the most brain dumb *threaded* MPMs) receive its own
apr_pool_t and thread. So, there won't be the possibility for contention
in the common case. However, APR assumes that when APR_HAS_THREADS is
defined that any allocation must be mutually exclusive. This will just
be pointless overhead, since the pools are already isolated for one
request.
There should be some case to prevent acquiring and releasing locks in
the apr_pool_t when the caller can guarantee that we have no possible
contention (or if contention occurs, it's the caller's fault).
IMHO, this is a mismatch between APR and httpd-2.0. I'm not sure of the
best way to resolve this. But, the apr_sms_t stuff gives us an
opportunity to address this (if we can). -- justin