> > >>Now I know I'm missing something here, so maybe you can fill in the >>blanks for me. This doesn't seem like a problem that would hang the >>entire server or put a hard limit on the number of concurrent connections >>(across processes). I would expect a finishing worker thread to return >>to the queue and immediately try to pick up an accepted and queued >>connection, waking up the listener thread if it was waiting for a slot >>to free up in the queue. Is this not the case? Where does the listener >>thread block in such a way that it prevents other idle threads from >>processing incoming requests? >> >>-aaron >> > >That sounds like a bug in the worker queue code (preventing the accept thread from >being >awakened if the queue is 'almost' full...) > >Bill >
The problem isn't that the busy worker threads will never become unbusy and pick up new work from the queue. If the queue is full, and the listener is blocked, the listener will (with the current code) be properly awakened as soon as one of the workers finishes its current connection. The problem is that it could be a long time before that happens, if all the workers are handling very long-lived connections. And meanwhile, there could be other child procs with idle worker threads. Which all leads me back to the conclusion that we need to stop managing a separate queue within each child process. (In the short term, though, blocking the listener from doing an accept if the # of idle workers is zero would be a reasonable alternative.) --Brian
