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
