5261dd7b01
qemu_co_queue_next does not need to release and re-acquire the mutex, because the queued coroutine does not run immediately. However, this does not hold for qemu_co_enter_next. Now that qemu_co_queue_wait can synchronize (via QemuLockable) with code that is not running in coroutine context, it's important that code using qemu_co_enter_next can easily use a standardized locking idiom. First of all, qemu_co_enter_next must use aio_co_wake to restart the coroutine. Second, the function gains a second argument, a QemuLockable*, and the comments of qemu_co_queue_next and qemu_co_queue_restart_all are adjusted to clarify the difference. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20180203153935.8056-5-pbonzini@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Signed-off-by: Fam Zheng <famz@redhat.com> |
||
|---|---|---|
| .. | ||
| 9p-iov-marshal.c | ||
| 9p-iov-marshal.h | ||
| 9p-marshal.c | ||
| 9p-marshal.h | ||
| file-op-9p.h | ||
| Makefile.objs | ||
| qemu-fsdev-dummy.c | ||
| qemu-fsdev-opts.c | ||
| qemu-fsdev-throttle.c | ||
| qemu-fsdev-throttle.h | ||
| qemu-fsdev.c | ||
| qemu-fsdev.h | ||
| virtfs-proxy-helper.c | ||
| virtfs-proxy-helper.texi | ||