Greg Ames wrote: > Brian Pane wrote: > >> Looking at the pattern of calls to ap_core_output_filter() in the >> event MPM, it occurred to me that it may be straightforward to hand >> off the writing of the request to an async completion thread in a lot >> of useful > >> real-world cases. > >> >> In function check_pipeline_flush() in http_request.c, a flush bucket >> is passed to the output filter stack if there's no pipelined request >> ready to be read (or if keep-alives aren't enabled for the connection). > > > good observation. these cases are common and simpler to deal with in > event than the pipelined input data present case. > >> When this occurs, two things are true: >> * One or more complete responses--and no partial responses--have been >> sent to the output filter stack for this connection. >> * If these responses have not been sent to the client, they will now >> be sent in their entirety before the httpd attempts to do any >> further reads from this connection. >> >> Instead of sending a flush bucket to the output filter stack in this >> scenario, though, perhaps we could send a new metadata bucket that >> denotes "end of output until everything currently in the pipeline has >> been written." > > > <nitpick> what's wrong with using the flush bucket? I think you're > suggesting a new improved way to process it. </nitpick> > >> Upon receiving this bucket, core_output_filter would register the >> connection with a pollset to watch for writability. >> >> A write completion thread would poll in an endless loop, writing data >> from >> each set-aside brigade whenever its corresponding connection became >> writable. >> Upon sending the last bucket of a set-aside brigade to the network, >> the completion >> thread would put the connection in either CONN_STATE_LINGER or >> CONN_STATE_CHECK_REQUEST_LINE_READABLE state (depending on >> whether keepalives were enabled) and re-register the connection with the >> event MPM's main pollset to wait for readability or timeout. >> >> The pollset used to wait for writability could be the same pollset >> that's currently used to watch for readability and timeouts. >> Similarly, the write completion thread could be combined with the >> current listener thread. > > > I would combine the pollsets/threads right away to save later work. I > think Paul Q. did a fair amount of work to merge the separate event > thread from my + Bill Stoddard's event patch into the listener thread.
FWIW, trunk has been using a combined listener/readability thread for a long time now... I have been thinking about adding the writ ability stuff, maybe ill have a chance to play with it this weekend on some more airplanes. -Paul
