Re: [Patch] proof of concept - teaching hooks to yield where sensible

Would it be possible to leverage something like libdill (http://libdill.org) for that? > On Feb 19, 2018, at 5:24 AM, Graham Leggett wrote: >> > > This is the problem I want to solve - I want to be able to run multiple > connections, and allow them to yield to each other. >

Re: [Patch] proof of concept - teaching hooks to yield where sensible

On 19 Feb 2018, at 11:45 AM, Yann Ylavic 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

Re: [Patch] proof of concept - teaching hooks to yield where sensible

> Am 19.02.2018 um 11:24 schrieb Graham Leggett : > > On 19 Feb 2018, at 11:14 AM, Stefan Eissing > wrote: > >> If I understand your gist correctly, this would allow HTTP/2 processing to >> return to the main (async) event loop more often.

Re: [Patch] proof of concept - teaching hooks to yield where sensible

On 19 Feb 2018, at 11:14 AM, Stefan Eissing wrote: > If I understand your gist correctly, this would allow HTTP/2 processing to > return to the main (async) event loop more often. Which would be great. > > In the case of HTTP/2, it would be even more cool, to

Re: [Patch] proof of concept - teaching hooks to yield where sensible

On Sun, Feb 18, 2018 at 12:11 AM, Graham Leggett 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,

Re: [Patch] proof of concept - teaching hooks to yield where sensible

If I understand your gist correctly, this would allow HTTP/2 processing to return to the main (async) event loop more often. Which would be great. In the case of HTTP/2, it would be even more cool, to trigger the (re-)processing of an AGAIN connection from another thread. The use case is: H2