> "Bill Stoddard" <[EMAIL PROTECTED]> writes: > > > > Right, the problem is that the listener needs to avoid doing the > > > accept if the queue is full. > > > > > > That part is easy: add a "block_if_queue_full()" method on the > > > fd_queue class, and have the listener call it before doing an > > > accept. > > > > > > > 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... > > That is the problem I thought was being dealt with originally... > After seeing it stated differently a couple of times I figured I was confused. > > probably-stupid idea: > > Maybe a counter of blocked threads can be cheaply maintained within the > existing serialization. The listener can use this to decide if it > should call accept() or give up the CPU. > > But this bites > > 1) when there is just one child process (wasted syscall) > > 2) because it would normally go faster if the listener could stay just > ahead of the workers so that workers can dequeue new work when they > finish with the old without having to wait on the listener to > enqueue something > > -- > Jeff Trawick | [EMAIL PROTECTED]
Sounds like a reasonable solution. I doubt you could measure the performance difference due to a wasted syscalls. And you can always play some games with the counters to enable you to accept a few additional connections (however you define 'few') in order to keep some work in the queue. Bill
