>>> On 3/15/2006 at 2:34 pm, in message <[EMAIL PROTECTED]>, "Jeff Trawick" <[EMAIL PROTECTED]> wrote: > Plz forgive any misunderstanding, as well as my use of 2.0 function > names ;) Also, for being slow at learning what ldap stands for. I > know this code has been hashed over many many times over the last few > years. > > util_ldap_create_config() creates the per-server config for util_ldap. > That saves a config-time pool in the per-server config. > > util_ldap_connection_find() is called on a request and allocates a > mutex using st->pool without holding a mutex, if the mutex wasn't > created before. IOW, the first <very-small-number> of threads in that > process that try to find a connection will allocate a mutex. > Hopefully very-small-number is one > > (This is exactly the type of bug I had the displeasure of diagnosing > in a proprietary module some time back; somebody eons ago had deferred > some initialization until the first request, assuming incorrectly that > there was no way that at the time of the first request for a certain > vhost that there would actually be 2+ concurrent requests stomping on > each other. one of the baby bells proved otherwise continually until > the problem was found and fixed) > > The child init hook really needs to talk the server_recs and create > the mutex there, right? > > Also, is the pool growth of the config-time pool reasonable? > > What happens when some other module cheats and uses a config-time pool > on request processing thread, even if it is "smart" enough to protect > the pool misuse with a mutex? (kaboom) > > If it is reasonable to grow some pool over time during the request > processing, shouldn't it be an ldap-unique pool
I think you are right. I am going to take a closer look at that code and see about fixing both the mutex problem and the use of the config pool. This could actually explain some funny things that I have been seeing on the NetWare build lately. Brad
