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
Description: Binary data