Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Mar 14, 2013 at 10:04:23AM +0000, Peter Maydell wrote:
> On 13 March 2013 12:34, Anthony Liguori <anthony@codemonkey.ws> wrote:
> > AioContext is necessary for the block layer because the block layer
> > still has synchronous I/O.  I think we should aim to replace all sync
> > I/O in the long term with coroutine based I/O.
> 
> I think coroutines are dreadful and we should really not be moving
> towards greater use of them. They're just really really not portable
> and they don't fit with the C language, and they're a constant source
> of problems.(For instance I have a bug I need to look into where we
> seem to hang using the gthread coroutine backend but not sigaltstack.)
> 
> Use threads, or a genuinely asynchronous API, or a select/poll loop
> with callbacks, but not more coroutines please.

You're right that coroutines make it harder to support QEMU across host
operating systems.

Why we have coroutines
======================
That said, we need an alternative mechanism for writing sequential code.
If we went through the effort of converting all coroutine and blocking
code to asynchronous callbacks the codebase would be very hard to
understand:

Straightforward operations would be split into many little callbacks.
Local variables would turn into state that gets passed between
callbacks.  This sort of code is much harder to reason about and is why
coroutines were introduced.

Coroutines allow us to keep the block layer and some of its users
readable.  Removing them would not only be a big effort, but would also
make the codebase worse.

An alternative to stack switching
=================================
I was looking at a second approach when considering the options:
continuation passing style transformation.  The following research
project implements an extension to C for writing sequential code that
gets converted to callbacks:

http://www.pps.univ-paris-diderot.fr/~kerneis/software/cpc/

Quick summary of how it works:
Continuating passing functions are marked with coroutine_fn, similar to
how we already do it in QEMU.  There are APIs to create new coroutines
and to yield.  The trick is that stack switching is not used and
therefore this approach is portable C.  Instead the code is translated
to callbacks at build-time and variables are automatically passed on the
heap in a "thunk" buffer.

I chatted with the authors and it looks like a good approach.  The
problems are:

1. Uses OCaml compiler framework.  Should this be part of gcc or an
   external tool that is easily consumed on all QEMU host platforms?

2. Debug information - need to make sure that callbacks map back to
   sequential code.

3. Maturity - cpc isn't used much to my knowledge.

I'm willing to mentor a Summer of Code project that attempts to replace
coroutines with cpc.  There's no guarantee it can replace coroutines due
to the issues I listed, but I think it's worth a shot.

Peter: Does this approach address your concerns about coroutines?

Thoughts about using a build-time tool instead of run-time stack
switching?

Stefan