On Sun, Feb 18, 2018 at 12:11 AM, Graham Leggett <minf...@sharp.fm> wrote:>
> As an extension to the idea of filters being async and being able to
> yield and break up their work into small chunks, I am keen to extend
> that idea to selected hooks.
> The patch below is a proof of concept, showing what it might look
> like if the pre_connection and process_connection hooks were able to
> return the code AGAIN. This means “please call me again”.
> In implementing this, we would start at the outermost hook, and then
> work inwards. We would also need to change these void functions to
> return ints, so that AGAIN could bubble upwards. Eventually the
> handler hook will be able to return AGAIN.
> Any module that doesn’t yield just behaves as modules do now.

We already have some event's mechanism(s) be async at the handler
layer (write completion, callbacks in trunk).
The "common connection state/milestone" proposal looks interesting for
compatibility (maybe add new CONN_STATEs instead of the similar
milestone type?).
However the most challenging part seems to be in/output filters part,
they currently handle EAGAIN like a real error (logging, brigade
cleanup, ...) and usually don't expect to be called again.

We can surely address all the cases upstream, what about third parties?


Reply via email to