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
--

Attachment: httpd-async-fullstack-ssl6.patch
Description: Binary data

Reply via email to