Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <6.1.2.0.2.20041026140920.02867ec0@pop3.rowe-clan.net>
Date: Tue, 26 Oct 2004 14:20:53 -0500
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: Event MPM
Cc: dev@httpd.apache.org
In-Reply-To: <367F12B66656DB66657E9F25@[10.0.1.57]>
References: <417C653D.9070202@outoforder.cc>
 <367F12B66656DB66657E9F25@[10.0.1.57]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 01:59 AM 10/26/2004, Justin Erenkrantz wrote:

>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.)

Justin, that's the purpose of a Poll bucket.  If we introduce the
concept, here's the scenario; whenever a 'speculative' or 'non blocking'
read or write is attempted and fails, at whatever depth (the socket
or the ssl filter itself), a metadata bucket comes back saying
'I got stuck - here!  Wait on this fd/event.'

With a little more clever magic, the thread handling that request
would psh this request, and that poll event, back to the 'event
manager', and yield to the event manager for another request
(maybe the same request) to be processed.

Someone cried wolf, b.t.w., about connection and request pool
allocation being too tightly coupled to threads.  They can be
decoupled pretty painlessly, by tying an allocator to a single
connection object.  We can presume that request pools will be 
a subpool of each connection.  Note - there are usually more 
connections than actual worker threads.  Also note, clever
httpd-2.0 tricks like mtmalloc can't work under this model.

>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 think you are oversimplifying.  3rd party modules expect they
will remain glued to a thread.  When a request can start to 'bounce'
between threads, we will likely need to push to 3.0.