On 19 Feb 2018, at 11:45 AM, Yann Ylavic <ylavic....@gmail.com> wrote:

> 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?).

The milestones are completely independent of the connection state, they simply 
mean “in this module, in this function, we have successfully got this far, if a 
hook returned AGAIN, continue from here and do not repeat hooks that have 
completed successfully”.

> 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.

This is a solved problem in trunk.

It turned out the network filter was async already, and had the ability to be 
called again. In the async filter patches I abstracted this behaviour out and 
taught other filters how to do this - most notably mod_ssl.

This problem doesn’t even need to be solved for this to work - if a module 
chooses not to return AGAIN, that’s completely fine.

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

Third party modules just work like they have before, and the behaviour is the 
same as before - a slot is consumed until done.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to