On 01/25/2018 11:59 AM, Paolo Bonzini wrote: > 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 <pbonz...@redhat.com> > ---
> /** > - * Restarts all coroutines in the CoQueue and leaves the queue empty. > + * Empties the CoQueue; all coroutines in it will run in FIFO orer as soon s/orer/order/ > + * as the current one yields. > */ > void coroutine_fn qemu_co_queue_restart_all(CoQueue *queue); -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
