Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <44192F26.6720.00AC.0@novell.com>
Date: Thu, 16 Mar 2006 09:27:56 -0700
From: "Brad Nicholes" <BNICHOLES@novell.com>
To: <trawick@gmail.com>,<dev@httpd.apache.org>
Subject: Re: pool use/mutex initialization in util_ldap not thread
	safe?
References: <cc67648e0603151334k3201e0ag4d2b936214bf0c78@mail.gmail.com>
  <441846B7.6720.00AC.0@novell.com>
  <cc67648e0603151849u5b04982cta11053f8b3ae9319@mail.gmail.com>
  <441956D0.7080309@apache.org>
 <cc67648e0603160612m21d9f220r96aff3612cc6ff84@mail.gmail.com>
In-Reply-To: <cc67648e0603160612m21d9f220r96aff3612cc6ff84@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>>> On 3/16/2006 at 7:12 am, in message
<cc67648e0603160612m21d9f220r96aff3612cc6ff84@mail.gmail.com>, "Jeff
Trawick"
<trawick@gmail.com> wrote:
> On 3/16/06, Ruediger Pluem <rpluem@apache.org> wrote:
>>
>>
>> On 03/16/2006 03:49 AM, Jeff Trawick wrote:
>> > On 3/15/06, Brad Nicholes  wrote:
>>
>> >
>> > That is really one pool globally but there is a mutex per
server_rec.
>> > So a thread handling a request for one vhost grabs the mutex and
uses
>> > the pool but that doesn't protect from a thread handling a request
for
>> > a different vhost which grabs a different mutex supposedly
protecting
>> > the same pool.
>>
>> Would it help to create sub-pools per server_rec from the config
pool?
> 
> That sounds like a definite improvement, but I'm eager for LDAP
gurus
> to explain how pool growth is mitigated in the current design
> (assuming thread safety) before jumping to a conclusion

The use of the pool is actually fairly limited.  It is used to create
and initialize the reusable LDAP resources such as ldap connections. 
The pool of ldap connections can grow but that is based on the amount of
traffic that requires LDAP authentication.  Even under very heavy use,
the number of connections in the connection pool might be ~20 but even
that is a generous number.  Any per-request memory allocations are done
from the request pool.  So the potential for collisions within the
global memory pool, although not 0, would be very low.

The purpose of the mutex is not necessarily to protect the memory pool
but to protect the ldap connection pool.  Whenever mod_ldap needs to
pull a connection from the ldap connection pool, it first grabs the
mutex so that it is free to search for a connection and modify its
parameters without having to worry about other threads doing the same
thing.  Since most of the global memory pool usage, outside of module
initialization, also occurs after the connection pool mutex has been
locked, this also lessens the chance of memory pool collisions.

However, given all of there, I still think that there are things that
need to be cleaned up especially with the mutex allocation and use in a
worker MPM environment.

Brad