httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
Subject Re: event MPM: async write completion?
Date Thu, 04 Aug 2005 08:49:53 GMT
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
>> 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.


View raw message