Justin Erenkrantz wrote:
this MPM breaks any pipelined connections because there can be a deadlock.
core_input_filter or any connection-level filter (say SSL) could be holding onto a complete request that hasn't been processed yet. The worker thread will only process one request and then put it back on the stack. But, there's certainly no reason why another request isn't already in the chain ready to be read. And, the listener/event thread will be waiting for more data to come in - but, we already read it. Oops.
Yes, this needs to be fixed. I don't see it as difficult problem. We already test for whether the output filters need to be flushed (i.e., is there any more data in the input filter chain) before the request ends. We just need need to remember the outcome of that test and react appropriately.
Are there a lot of browsers out there that implement true pipelining? I know it's in the RFC for good reasons but I don't believe I've ever seen it in the wild.
(And, perhaps, it's not enough to be a complete request - so it'd
block defeating the purpose of the event thread
umm, I disagree. I'm not too concerned about worker threads blocking in socket reads occasionally. The point here is to go after the low hanging fruit (frequent long delays between requests) without massive code churn in the server.
Greg
