diff options
| author | Paolo Bonzini <pbonzini@redhat.com> | 2018-02-03 10:39:34 -0500 |
|---|---|---|
| committer | Fam Zheng <famz@redhat.com> | 2018-02-08 09:22:03 +0800 |
| commit | 5261dd7b0106a88c9b323607136b1dfa1d7db689 (patch) | |
| tree | 6463067b5849821f9639f5a3b5bcfd70513ac57c /qapi/qobject-output-visitor.c | |
| parent | 1a957cf9c4637abe4b7d67a91312a2565306641e (diff) | |
| download | focaccia-qemu-5261dd7b0106a88c9b323607136b1dfa1d7db689.tar.gz focaccia-qemu-5261dd7b0106a88c9b323607136b1dfa1d7db689.zip | |
coroutine-lock: make qemu_co_enter_next thread-safe
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>
Diffstat (limited to 'qapi/qobject-output-visitor.c')
0 files changed, 0 insertions, 0 deletions