httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: event mpm
Date Sat, 11 Feb 2006 20:02:50 GMT
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:

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_*.


View raw message