On Oct 9, 2008, at 4:53 PM, Greg Ames wrote:
On Tue, Oct 7, 2008 at 7:03 PM, Ruediger Pluem <[EMAIL PROTECTED]>
wrote:
I am currently looking at PR45605 (https://issues.apache.org/bugzilla/show_bug.cgi?id=45605
)
and the analysis and the resulting patch in Comment 4 look good to me
(https://issues.apache.org/bugzilla/show_bug.cgi?id=45605#c4). As
worker and event MPM
are very similar I had a look if and how this patch is applicable to
the event MPM.
I noticed that ap_queue_info_wait_for_idler is quite different in
worker and event MPM.
I don't think the problem reported by PR45605 exists in the Event MPM.
AFAICT, I don't think so either.
I had to stare at ap_queue_info_wait_for_idler for a long time back
when it could be called by two separate threads. The unserialized
access to queue_info->idlers followed by the unconditional decrement
outside of the mutex in that section of code made my head twitch
when I thought about races on SMP systems.
The two major improvements in Event's fdqueue are:
* doing the atomic decrement first before making a decision about
waiting. The decrement is visible to other threads immediately.
* using the negative value of idlers to distinguish between when
threads (just the listener today) are waiting for idle workers vs.
when all workers are busy but nobody else (the listener) is
blocked. That eliminates a situation where the condition variable
is signalled unnecessarily, which happens in the PR scenario.
Comparing the 2, it does appear that Event includes improvements that
would benefit Worker and vice versa...
