On Tue, Oct 6, 2015 at 12:57 PM, Graham Leggett <minf...@sharp.fm> wrote: > > On 06 Oct 2015, at 12:36 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> BTW, I wonder if we can "reinstate" the filters in arbitrary order >> like in the above loop (the order seems to depend on the calls to >> ap_filter_setaside_brigade() and internal apr_hash_t ordering). >> Don't we need to start from r->ouput_filters down to the last filter >> and call ap_pass_brigade(f, c->empty) if f is in the hashtable? > > No - we don’t “reinstate” filters in any way, we just kick them. We kick each > eligible filter exactly once on each pass, and the order doesn’t matter. > Every filter with data in it gets a kick to ensure no filter is starved, all > filters without data are silently ignored.
What I meant is that passing an empty brigade to a reinstate-able filter may make it pass its data to the next filter, so we may want to do this only on the first reinstate-able filter starting from r->output_filters. So it seems to me that order matters, but I must be missing something, need to think more about this. Regards, Yann.
