httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <>
Subject Re: Proposed connection state diagram
Date Sat, 17 Sep 2005 01:19:16 GMT
Paul Querna wrote:
> 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.


I see a tiny difference from the current event MPM implementation.  a 
new connection initially goes into CONN_STATE_READ_REQUEST_LINE.  it 
could easily be done as drawn too...the decision was almost a toss up. 
but since several OSes have some sort of accept filtering in the kernel 
which checks for data present along with the connection, and since I 
rarely see connections in 'R' state, I decided to skip the overhead of 
an initial poll() for readability.

>>Should there be an "access logger" state?  Are there other good use 
>>cases to consider
>>for a nonblocking handler feature, besides mod_proxy?

I am still catching up, but anything that we know is really slow that 
doesn't need a worker I/O (LDAP in addition to proxy), 
maybe CGIs, although it may be silly to worry about worker thread usage 
when CGIs are eating processes.

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

I rarely see 'L' state in server-status, so IMO logging would be a low 
priority for async.  but who knows, it might be important for somebody 
to use a Java logger which writes to network attached storage (shudder). 
    I'd rather keep logging on a worker thread for now, just in case.


View raw message