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.
amen.
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 thread...network 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.
Greg
