event mpm

["Scott A. Guyer" <sa...@verizon.net>]

Hi,

  I would like to know more about the process 
flow of the event MPM.  The docs indicate it was largely
about moving listening logic for keep-alives out of the
worker threads and into the listener thread.  The name
implies to me that it might be more general than that
(for example, supporting a more cooperative task management
with the working threads).

  My interest is that I would like to know if the event
MPM is on the path to support content handlers that utilize
Asynchrous/non-blocking I/O.  So that the content handler
could yield control back to worker thread so a new task
could be scheduled to it while the previous task waits
for the async I/O to wakeup.

  Make sense?  Ludicrous?  All feedback welcome.  Please
help point me in the right direction.  For example, if
the event MPM is the right place to start, or a whole new
MPM would have to be written?  Thanks for your advice.

-Scott (saguyer@acm.org)

Re: event mpm

[Greg Ames <gr...@apache.org>]

Scott A. Guyer wrote:

>   I would like to know more about the process 
> flow of the event MPM.  The docs indicate it was largely
> about moving listening logic for keep-alives out of the
> worker threads and into the listener thread.  

the basic concept of the event MPM is to reduce the amount of time that worker threads 
spend blocked on network I/O, without introducing a lot of complexity into the HTTP 
protocol engine.  I picked keep-alive waits for the first type of event because:

* keep-alive timeouts are handled when no HTTP request is active, reducing complexity by 
minimizing the amount of state info that needs to be maintained across the waits
* KA timeouts can tie up a high percentage of worker threads, as seen here: 
http://apache.org/server-status

since then, Brian Pane has extended the design to also handle socket write waits for big 
file downloads.  another fairly obvious extension would be to handle the read delays for 
lingering close.  notice how many 'C's appear in the server-status display above.

> The name
> implies to me that it might be more general than that
> (for example, supporting a more cooperative task management
> with the working threads).

>   My interest is that I would like to know if the event
> MPM is on the path to support content handlers that utilize
> Asynchrous/non-blocking I/O.  So that the content handler
> could yield control back to worker thread so a new task
> could be scheduled to it while the previous task waits
> for the async I/O to wakeup.

the event MPM is a finite state machine with a small set of states geared toward common 
network I/O operations on the browser connection.  I don't really see it as a generalized 
asynch I/O mechanism.  however there is nothing that stops a handler for doing 
non-blocking I/O for its own purposes.

you should get a pretty good feel for how the event MPM works by looking at the code which 
references CONN_STATE_*.

Greg