https://issues.apache.org/bugzilla/show_bug.cgi?id=45605
--- Comment #8 from Jeff Lawson <[EMAIL PROTECTED]> 2008-10-08 08:41:36 PST --- This latest report is a legitimate bug, as can be seen by following events through the given scenario. However it is not the exactly the same bug as originally reported. As can be seen by reviewing the assert condition that the original bug reporter was having, the original condition was an overflow not an underflow. Here is the scenario where the overflow can happen. 1. Listener thread is waiting for workers. 1. Worker threads are all busy but one that just finished. 2. That worker thread atomically increments idlers from 0 to 1 and awakens the listener. 3. That worker thread context switches (before getting into ap_queue_pop()) 4. Listener awakens and finds that there is an idle worker and begins to fill the queue (ap_queue_push()), repeatedly until queue is overfilled. Unfortunately the fix provided by Denis does not address this problem. The root of the problem is that there is no way for the listener to indicate that it is idle, then execute code outside of a critical section, and then pick up the work to be done without this timing window being present. The possible solutions are: - Have the idler not indicate it is ready to process a request before it is actually in the critical section where it will pick up the work to be processed. This is not trivial using the current architecture of having the queue and queueinfo structures being separate structures. - Have the listener wait if the queue is full as Chris' patch does. This introduces and an extra condition variable, and an extra mutex lock for each request. (Might be able to mitigate the mutex lock cost to almost zero by only locking when the queue is full) - To minimize code changes we could simply gracefully exit the child when the queue is full allowing those requests to finish but no more requests to be processed by this child. I don't like this solution because it makes more work (child startup/shutdown) right when the system is already overloaded. Comments? Other possibilities? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
