> 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
That sounds like a bug in the worker queue code (preventing the accept thread from being awakened if the queue is 'almost' full...) Bill
