On Thu, Apr 11, 2002 at 03:04:27PM -0400, Bill Stoddard wrote: > I am not an expert on the worker MPM but I don't think that is an accurate statement >of > the problem. The accept thread uses ap_queue_push() to enqueue a socket for the >worker > threads. ap_queue_push() will block if the queue is full. > > The problem is that the queue can be EMPTY even when all the worker threads are busy > handling connections. The way the code is today, the queue can hold >ap_threads_per_child > elements. Now consider 2 x ap_threads_per_child connections comming into the server >at > once.. The first 1 x ap_threads_per_child connections will be accepted and handled >by the > worker threads. The next ap_threads_per_child connections will get queued and this is > precisely the problem...
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
