httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: Proposed connection state diagram
Date Mon, 05 Sep 2005 16:17:02 GMT
Brian Pane wrote:
> On the subject of asynchronous write completion, I've drawn a 
> connection state model that
> combines the current state transitions of the event MPM with new  states
> for write completion
> and the handler phase.

Very cool diagram.

Right now, I am trying to understand the implications of a Handler
state. It says we only shift states from Handler -> Write Completion
once we have the 'Full Request Generated'.  So does this mean the
Handler will write to the client at all?

In my insane vision that I have never written down anywhere before, I
thought we would just save brigades onto a buffer inside the C-O-F.  As
soon as *any* data was buffered it would go into the write completion
state.  I guess it actually makes sense to have a Handler state.  When
we are in the Handler state, we know more data is coming.  Once we are
in write completion, as soon as we are done sending data, the request is
finished.

> Comments welcome... Am I missing any state transitions (particularly 
> for error cases)?
> Should there be an "access logger" state?  Are there other good use 
> cases to consider
> for a nonblocking handler feature, besides mod_proxy?

Logging Sucks.  On Fast Machines, it wouldn't be a huge hit, and most
likely could run inside the event thread.  However, we also might not be
logging to a file... there are plenty of other modules that log to
remote machines too.  I guess my view is that we should let any blocking
operation be handled by a Worker Thread, and Logging still seems like
one that cannot always be distilled into non-blocking operations.

 -Paul

Mime
View raw message