I believe this is a bare-bones essential patch required for getting POD
to work correctly under threaded MPM. The apr_recv() may return success
but return 0 length (indicating the pipe is fine, but there were not any
characters to read). Therefore, we should check the returned length
being 1. The code in mpm_common.c already does this.
Ryan has suggested before using the code in mpm_common.c (and I had
submitted a patch to do that), but, after some discussions with Roy and
more pondering of the problem, that will break the poll() code (which
effectively stops the never-exit-even-though-w_m_e-is-set problem
discussed before on systems with S_L_U_A). OSes without S_L_U_A (i.e.
Solaris) still do have this deadlock situation because of the
cross-process mutex.
However, I believe that we could shift the cross-process mutex
acquisition to after the poll tells us to read even on non-S_L_U_A
calls. This does introduce a thundering-herd problem though. All
of the threads will listen with the poll, wakeup, check w_m_e, and
then try to acquire the lock (actually, we'd need a tryacquire - if
it fails, they go back to the poll code rather than waiting). If
they succeed, they have the mutex and can do apr_acquire. -- justin
Index: threaded.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/mpm/threaded/threaded.c,v
retrieving revision 1.44
diff -u -r1.44 threaded.c
--- threaded.c 2001/07/03 13:58:10 1.44
+++ threaded.c 2001/07/17 22:29:52
@@ -511,7 +511,8 @@
else {
/* It won the lottery (or something else is very
* wrong). Embrace death with open arms. */
- workers_may_exit = 1;
+ if (n == 1)
+ workers_may_exit = 1;
}
}
apr_lock_release(pipe_of_death_mutex);
