apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: Pools & locking?
Date Thu, 17 May 2001 18:28:34 GMT
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

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

View raw message