httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45605] [Mon Aug 04 16:30:39 2008] [crit] [Mon Aug 04 16:30:39 2008] file fdqueue.c, line 293, assertion "!((queue)->nelts == (queue)->bounds)" failed
Date Wed, 08 Oct 2008 15:41:38 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=45605





--- Comment #8 from Jeff Lawson <jlawson@omniture.com>  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: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message