httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: Event MPM
Date Tue, 26 Oct 2004 19:20:53 GMT
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.

View raw message