httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject Re: pool use/mutex initialization in util_ldap not thread safe?
Date Thu, 16 Mar 2006 19:04:00 GMT
>>> On 3/16/2006 at 11:34 am, in message
<>, "Jeff
<> wrote:
> On 3/16/06, Brad Nicholes <> wrote:
>> >>> On 3/16/2006 at 7:12 am, in message
>> <>,
>> 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
>> uses
>> >> > the pool but that doesn't protect from a thread handling a
>> 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
>> and initialize the reusable LDAP resources such as ldap
>> The pool of ldap connections can grow but that is based on the
amount of
>> traffic that requires LDAP authentication.  Even under very heavy
>> the number of connections in the connection pool might be ~20 but
>> that is a generous number.
> if ldap server times out the connection and we have to bring one
> 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?

No, there is no growth there.  The cached or pooled information that
consumes memory, remains the same.  So there is no need to allocate more
memory.  If a connection times out or is broken for whatever reason, it
is just the connection that needs to be re-established given all of the
information that currently exists.  Also the growth does just occur when
we start talking to a new LDAP server.  It occurs when we run out of
connections to an LDAP server and require a new one.  This may involve
more than one LDAP server but in most cases it is just multiple
connections to the same LDAP server.

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

Right which is why I believe that there is work to be done here.

>> The purpose of the mutex is not necessarily to protect the memory
>> but to protect the ldap connection pool.  Whenever mod_ldap needs
>> 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
>> thing.  Since most of the global memory pool usage, outside of
>> initialization, also occurs after the connection pool mutex has
>> locked, this also lessens the chance of memory pool collisions.
>> However, given all of there, I still think that there are things
>> 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
> (I can't remember at the moment if a freestanding pool keeps it from
> being cleaned up at child process exit)
> or
> 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

I am still looking at the code, but my gut feel is that child-init may
not be the best place to create the pool or the mutex.  All of this is
vhost based and should remained separated in that way.  Another problem
is that memory allocations need to occur during config time which
happens before child-init gets called.


View raw message