httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: Event MPM
Date Tue, 26 Oct 2004 16:03:48 GMT
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


Mime
View raw message