httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject pool use/mutex initialization in util_ldap not thread safe?
Date Wed, 15 Mar 2006 21:34:35 GMT
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?

Mime
View raw message