Re: [Qemu-devel] [Qemu-block] [RFC PATCH] coroutines: generate wrapper code

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

On Tue, Feb 12, 2019 at 10:03:19AM +0000, Vladimir Sementsov-Ogievskiy wrote:
> 12.02.2019 6:22, Stefan Hajnoczi wrote:
> > On Mon, Feb 11, 2019 at 09:38:37AM +0000, Vladimir Sementsov-Ogievskiy wrote:
> >> 11.02.2019 6:42, Stefan Hajnoczi wrote:
> >>> On Fri, Feb 08, 2019 at 05:11:22PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> >>>> Hi all!
> >>>>
> >>>> We have a very frequent pattern of wrapping a coroutine_fn function
> >>>> to be called from non-coroutine context:
> >>>>
> >>>>     - create structure to pack parameters
> >>>>     - create function to call original function taking parameters from
> >>>>       struct
> >>>>     - create wrapper, which in case of non-coroutine context will
> >>>>       create a coroutine, enter it and start poll-loop.
> >>>>
> >>>> Here is a draft of template code + example how it can be used to drop a
> >>>> lot of similar code.
> >>>>
> >>>> Hope someone like it except me)
> >>>
> >>> My 2 cents.  Cons:
> >>>
> >>>    * Synchronous poll loops are an anti-pattern.  They block all of QEMU
> >>>      with the big mutex held.  Making them easier to write is
> >>>      questionable because we should aim to have as few of these as
> >>>      possible.
> >>
> >> Understand. Do we have a concept or a kind of target for a future to get rid of
> >> these a lot of poll-loops? What is the right way? At least for block-layer?
> > 
> > It's non-trivial.  The nested event loop could be flattened if there was
> > a mechanism to stop further activity on a specific object only (e.g.
> > BlockDriverState).  That way the event loop can continue processing
> > events for other objects and device emulation could continue for other
> > objects.
> > 
> > Unfortunately there are interactions between objects like in block jobs
> > that act on multiple BDSes, so it becomes even tricky.
> > 
> > A simple way of imagining this is to make each object an "actor"
> > coroutine.  The coroutine processes a single message (request) at a time
> > and yields when it needs to wait.  Callers send messages and expect
> > asynchronous responses.  This model is bad for efficiency (parallelism
> 
> hmm, and with all these loops, where is parallelism?

In this model all activity, including the async operations that work in
parallel today, go through an actor coroutine.  The loss of parallelism
isn't in synchronous polling operations, it's in the async operations.

But I'm just using this as a simple model for reasoning about a world
where no synchronous polling loops are necessary.  I don't think we
would try to implement it - at least not without a lot more thought into
how to make it efficient.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]