I am debugging an httpd issue where two (otherwise unrelated) fcntl
based process mutexes are used on Solaris 10/em64t.
Two child processes in a threaded server share the file descriptors
for the two fcntl locks. One mutex is the httpd accept mutex, and the
other guards the mod_ldap shared memory cache.
proc1/listener holds the accept mutex (fcntl) and is blocked in portfs (poll)
proc2/listener is blocked on the accept mutex
proc2 has acquired the LDAP mutex
A thread in proc1 will get EDEADLK from fcntl() on the LDAP mutex
A potential for deadlock occurs if a process controlling a
locked region is put to sleep by attempting to lock another
process' locked region. If the system detects that sleeping
until a locked region is unlocked would cause a deadlock,
fcntl() will fail with an EDEADLK error.
(since the LDAP mutex is actually an apr_global_mutex, threads in
proc2 block correctly behind the thread mutex).
Latest maintenance from Sun didn't seem to make a difference. Is this
over-aggressive deadlock detection unique to Solaris, and is there any
way to cope with it other then building w/ a different default mutex
mech?
.--
Eric Covener
[EMAIL PROTECTED]
