On Fri, May 13, 2011 at 11:26 AM, Stefan Hajnoczi <stefa...@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 ? Thanks -- Corentin Chary http://xf.iksaif.net
