On 15 Sep 2014, at 2:13 PM, Graham Leggett <minf...@sharp.fm> wrote: > There is an issue I hadn’t considered - the effect of calling > ap_remove_output_filter(). > > If we remove the filter with buckets having been set aside, the > c->data_in_output_filters will remain unchanged and off-by-one, leading to a > spin (it will never count back down to zero). This is a nasty bug to have to > chase down. > > In the attached patch I have investigated adding both buffered_bb and the > deferred_write_pool to ap_filter_t, and having ap_remove_output_filter() “do > the right thing” when called. Both of these can be optionally set by the > caller, but are otherwise not handled by the caller, the filter API worries > about cleaning up, and worries about ensuring that c->data_in_output_filters > is always accurate. > > I have also introduced an optimisation where if this is a request filter, we > use r->pool to setaside buckets, while if we’re a connection filter we use > the deferred write pool. > > Looks like a similar thing needs to be done with input filters.
Another refinement - deferred_write_pool is now just deferred_pool, and we only manipulate the data_in_output_filters when removing an output filter. Regards, Graham —
httpd-async-fullstack-ssl5.patch
Description: Binary data
