Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Date: Mon, 25 Oct 2004 23:59:42 -0700
From: Justin Erenkrantz <justin@erenkrantz.com>
To: dev@httpd.apache.org
Subject: Re: Event MPM
Message-ID: <367F12B66656DB66657E9F25@[10.0.1.57]>
In-Reply-To: <417C653D.9070202@outoforder.cc>
References: <417C653D.9070202@outoforder.cc>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Sunday, October 24, 2004 8:30 PM -0600 Paul Querna <chip@outoforder.cc> 
wrote:

> I took this patch as the starting point for my 'Event MPM'.
...
> I would love feedback on all aspects of the patch. Please feel free to rip
> it apart :)

I just had a conversation on #apr with Paul.  But, I'll rehash the one issue I 
brought up there: 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.  (And, perhaps, it's not enough to be a 
complete request - so it'd block defeating the purpose of the event thread - 
Oops again.)

I'll note that serf (the async HTTP client library Greg and I are working on) 
had to deal with this same case.  The only suggestion I have is that 
ap_read_request() needs to be come async/non-blocking so that it can pick up 
requests that aren't 'ready' yet and return an 'EAGAIN' status code.  This is 
what we do with serf, but httpd doesn't have that luxury.

Greg, Manoj, and I (and many others) have talked for a long time about having 
a fully async MPM - on both read *and* writes we hand the thread over to the 
event thread.  When there is data to be read or we can write, we assign it to 
a thread.  This MPM is a step in the right direction towards that goal, but 
we'd have to solve the 'unprocessed, but read request' problem first.

FWIW, if we start to go down this route, to me this smells like 2.3 candidate 
work.  This is likely going to snowball real fast into other areas and I'd 
really like to keep us close to seriously discussing 2.2 at AC in a few weeks 
instead of throwing HEAD into turmoil with these changes.

I'll also note that flood would almost certainly trigger this as it uses 
pipelined requests - unlike ab which doesn't know pipelining.  =)  -- justin