httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <>
Subject Re: pool use/mutex initialization in util_ldap not thread safe?
Date Thu, 16 Mar 2006 18:34:05 GMT
On 3/16/06, Brad Nicholes <> wrote:
> >>> On 3/16/2006 at 7:12 am, in message
> <>, "Jeff
> Trawick"
> <> wrote:
> > On 3/16/06, Ruediger Pluem <> 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.

if ldap server times out the connection and we have to bring one back
up, that is no pool growth, right?  we just get pool growth when we
talk to an LDAP server we haven't already talked to yet, or when?

>                    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.

"very low" == still broken but much much harder to debug than "high"

> 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.

I interpret this as meaning that the following would resolve the
problems (race condition for mutex initialization between multiple
threads for the same vhost and race condition for pool use between
multiple threads in different vhosts):

1) this code needs LDAP-specific subpool of pchild* for each
LDAP-enabled vhost, initialized in child-init hook
2) the vhost-specific mutex is initialized in the child-init hook
(walk the server_rec list)

*do these objects need to get cleaned up when the process goes away? 
maybe it shouldn't be a subpool at all but instead a freestanding pool
(I can't remember at the moment if a freestanding pool keeps it from
being cleaned up at child process exit)


1) one global subpool of pchild* for each LDAP-enabled vhost,
initialized in child-init hook
2) one global mutex initialized in the child-init hook

It just depends on expected collision rate.

I see some pthread_mutex_trylock usage, which makes me think the
collision rate can be high, but it is unclear that segregating by
vhost makes much of an improvement.

View raw message