This is super cool magic mojo.
> On Sep 27, 2015, at 2:41 PM, Graham Leggett <[email protected]> wrote:
>
> 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
> --
> <httpd-async-fullstack-ssl6.patch>
