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. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
