Re: [Qemu-devel] [PATCH v3 0/4] Coroutines for better asynchronous programming

[Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>]

On Sat, May 14, 2011 at 08:55:40AM +0200, Corentin Chary wrote:
> On Fri, May 13, 2011 at 11:26 AM, Stefan Hajnoczi
> <stefanha@linux.vnet.ibm.com> wrote:
> > QEMU is event-driven and suffers when blocking operations are performed because
> > VM execution may be stopped until the operation completes.  Therefore many
> > operations that could block are performed asynchronously and a callback is
> > invoked when the operation has completed.  This allows QEMU to continue
> > executing while the operation is pending.
> >
> > The downside to callbacks is that they split up code into many smaller
> > functions, each of which is a single step in a state machine that quickly
> > becomes complex and hard to understand.  Callback functions also result in lots
> > of noise as variables are packed and unpacked into temporary structs that pass
> > state to the callback function.
> >
> > This patch series introduces coroutines as a solution for writing asynchronous
> > code while still having a nice sequential control flow.  The semantics are
> > explained in the first patch.  The second patch adds automated tests.
> >
> > A nice feature of coroutines is that it is relatively easy to take synchronous
> > code and lift it into a coroutine to make it asynchronous.  Work has been done
> > to move qcow2 request processing into coroutines and thereby make it
> > asynchronous (today qcow2 will perform synchronous metadata accesses).  This
> > qcow2 work is still ongoing and not quite ready for mainline yet.
> >
> > Coroutines are also being used for virtfs (virtio-9p) so I have submitted this
> > patch now because virtfs patches that depend on coroutines are being published.
> >
> > Other areas of QEMU that could take advantage of coroutines include the VNC
> > server, migration, and qemu-tools.
> 
> Hum, the VNC server is already threaded, how would coroutines help  ?
> Do you plan to rewrite the server using coroutines instead of threads
> ?

The main control flow in the VNC server is a state-machine.  Imagine a
VNC session running as sequential code in a coroutine instead of being
broken up across callbacks.  I think it would be easier to follow
although rewriting it now may not be worth the effort unless significant
future VNC work is planned for the future.

Stefan