>>> On 3/16/2006 at 7:12 am, in message <[EMAIL PROTECTED]>, "Jeff Trawick" <[EMAIL PROTECTED]> wrote: > On 3/16/06, Ruediger Pluem <[EMAIL PROTECTED]> 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
