/me like :) On Nov 21, 2013, at 8:57 AM, Graham Leggett <minf...@sharp.fm> wrote:
> Given that the world must be given an opportunity to migrate to async > filters, we would need to support both at the same time. > > What I am thinking is that a filter registers itself either as a legacy > synchronous filter (you'll be given a brigade, don't return until all the > brigade is consumed), or an asynchronous filter (feel free to return > APR_EAGAIN at any time, and setaside data if you receive APR_EAGAIN from > upstream), you state explicitly which. > > The key bit will be the transition from an upstream async filter to an > earlier sync filter, APR_EAGAIN will need to be trapped and responded to by > sending a flush bucket up the stack, effectively allowing us to convert > APR_EAGAIN into APR_SUCCESS which can then be safely received by the earlier > sync filter. This is a simple task that could be accomplished inside > ap_pass_brigade(). > > The event MPM would simply need to pass empty brigades to c->output_filters > until c->data_in_output_filters returns to zero. > > The addition of a sync filter to the c->output_filters would cause > write_completion to stop working, but it will still be functional until the > sync filter became async. > > We currently have this situation where we keep track of the start of the > protocol filter stack in c->output_filters instead of the real start of the > stack, we could for now insert a helper protocol filter that runs first and > waits until EOS is received meaning "synchronous processing is done", before > setting aside the data and returning APR_SUCCESS, inviting event to enter > write completion in the hope that everything from this filter onwards is > async and therefore eligible for write completion. This filter can also be > responsible for flow control, vastly simplifying the core_output_filter we > have now. > > All of this is still backportable to v2.4. > > Regards, > Graham > -- >
