On Sun, Feb 18, 2018 at 12:11 AM, Graham Leggett <[email protected]> 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? Regards, Yann.
