Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 17 May 2001 11:28:34 -0700
From: Justin Erenkrantz <jerenkrantz@ebuilt.com>
To: David Reid <dreid@jetnet.co.uk>
Cc: APR Development List <dev@apr.apache.org>
Subject: Re: Pools & locking?
Message-ID: <20010517112834.M23812@ebuilt.com>
References: <00a601c0deea$f5b865b0$71ac70d8@VAIO>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00a601c0deea$f5b865b0$71ac70d8@VAIO>;
 from dreid@jetnet.co.uk on Thu, May 17, 2001 at 05:03:29PM +0100

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