summary refs log tree commit diff stats
path: root/qapi/qobject-output-visitor.c
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2018-02-03 10:39:34 -0500
committerFam Zheng <famz@redhat.com>2018-02-08 09:22:03 +0800
commit5261dd7b0106a88c9b323607136b1dfa1d7db689 (patch)
tree6463067b5849821f9639f5a3b5bcfd70513ac57c /qapi/qobject-output-visitor.c
parent1a957cf9c4637abe4b7d67a91312a2565306641e (diff)
downloadfocaccia-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