httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: [Patch] Async write completion for the full connection filter stack
Date Sun, 27 Sep 2015 18:41:24 GMT
Hi all,

I think I have cracked the async problem for both request and connection output filters with
this patch.

It provides three new functions:

- ap_filter_reinstate_brigade() - Used at the start of a filter, brigades that were set aside
earlier are reinstated for sending.

- ap_filter_should_yield() - Returns true if downstream filters have set aside data. A filter
would typically respond by setting aside the data it is working with and returning in the
expectation of being called again.

- ap_filter_setaside_brigade() - Used at the end of a filter, any brigades that were not processed
can be set aside to continue the job when called later.

The magic happens in the MPM itself. The first time ap_filter_setaside_brigade() is called
the filter is added to a hashtable and a cleanup is registered to have the filter removed
when the request and/or connection is cleared. The MPM iterates through this hashtable, and
sends empty brigades to any filter with setaside data.

Key to this technique is that existing filters remain unaffected - in the absence of any changes
to a filter the whole brigade will be processed and sent downstream, and existing behaviour
is maintained. Same with FLUSH buckets - as expected, flush behaviour remains unchanged.

If however the filters in the chain are able to setaside buckets, they can defer themselves
to the write completion phase which in turn can take full advantage of the event MPM. These
filters will be expected to handle an empty brigade to “kick” them back into life and
continue the writing of their setaside data. As soon as their setaside brigade becomes empty
the kicks then stop. All filters with setaside data get kicked exactly once, so none of the
filters should get starved. Filters that are removed from the stack get their setaside emptied,
and so become ineligible for kicks. When the pool cleanup gets triggered, the filter is permanently
removed from the connection and disappears.

Over and above the network filter the first filter to be modified is mod_ssl, and this will
allow files served over SSL to take advantage of write completion. Another filter that will
benefit from using the above calls is mod_deflate.

I have an additional goal of adding an ap_filter_suspend() method that will allow us to suspend
a filter for a given period of time or until some callback is triggered, but that will be
a separate patch.

Regards,
Graham
--

Mime
View raw message