apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <I...@cnet.com>
Subject RE: Pools & locking?
Date Fri, 18 May 2001 00:13:33 GMT
so If I understand this thread correctly

we could removing the locking code from the allocation routines
(for use in running apache2.0 ) without any penalty?
as we are using thread based pools ????

maybe this can be a config option on the apr configure script (--disable-Memory-Pool-Locking


(I know I could just wait for the SMS stuff to get fully implemented, but
Im thinking we could fix it now, and later on remove the config option when
SMS is fully integrated)

> -----Original Message-----
> From: Justin Erenkrantz [mailto:jerenkrantz@ebuilt.com]
> Sent: Thu, May 17, 2001 11:29 AM
> To: David Reid
> Cc: APR Development List
> Subject: Re: Pools & locking?
> 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 
> 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

View raw message