qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 0/5] Coroutines for better asynchronous progr


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v5 0/5] Coroutines for better asynchronous programming
Date: Tue, 21 Jun 2011 14:26:50 +0100

On Sun, Jun 12, 2011 at 9:46 PM, Stefan Hajnoczi
<address@hidden> 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 second patch.  The fourth 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.
>
> v5:
>  * GThread-based implementation for platforms without makecontext(3) (Aneesh 
> Kumar K.V <address@hidden>)
>  * Switch to gtester test framework
>
> v4:
>  * Windows Fibers support (Paolo Bonzini <address@hidden>)
>  * Return-after-setjmp() fix (Aneesh Kumar K.V <address@hidden>)
>  * Re-entrancy for multi-threaded coroutines support
>  * qemu-coroutine.h cleanup and documentation
>
> v3:
>  * Updated LGPL v2 license header to use web link
>  * Removed atexit(3) pool freeing
>  * Removed thread-local current/leader
>  * Documented thread-safety limitation
>  * Disabled trace events
>
> v2:
>  * Added ./check-coroutine --lifecycle-benchmark for performance measurement
>  * Split pooling into a separate patch with performance justification
>  * Set maximum pool size to prevent holding onto too many free coroutines
>  * Added atexit(3) handler to free pool
>  * Coding style cleanups
>
> Aneesh Kumar K.V (1):
>  coroutine: implement coroutines using gthread
>
> Anthony Liguori (1):
>  Add hard build dependency on glib
>
> Kevin Wolf (1):
>  coroutine: introduce coroutines
>
> Stefan Hajnoczi (2):
>  coroutine: add check-coroutine automated tests
>  coroutine: add check-coroutine --benchmark-lifecycle
>
>  .gitignore           |    1 +
>  Makefile             |    5 +-
>  Makefile.objs        |   13 +++
>  Makefile.target      |    1 +
>  configure            |   29 +++++++
>  coroutine-gthread.c  |  131 ++++++++++++++++++++++++++++
>  coroutine-ucontext.c |  229 
> ++++++++++++++++++++++++++++++++++++++++++++++++++
>  coroutine-win32.c    |   92 ++++++++++++++++++++
>  qemu-coroutine-int.h |   48 +++++++++++
>  qemu-coroutine.c     |   75 ++++++++++++++++
>  qemu-coroutine.h     |   95 +++++++++++++++++++++
>  test-coroutine.c     |  192 ++++++++++++++++++++++++++++++++++++++++++
>  trace-events         |    5 +
>  13 files changed, 915 insertions(+), 1 deletions(-)
>  create mode 100644 coroutine-gthread.c
>  create mode 100644 coroutine-ucontext.c
>  create mode 100644 coroutine-win32.c
>  create mode 100644 qemu-coroutine-int.h
>  create mode 100644 qemu-coroutine.c
>  create mode 100644 qemu-coroutine.h
>  create mode 100644 test-coroutine.c

Any objections to merging this?

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]