On 24/01/2018 04:58, Fam Zheng wrote: > On Tue, Jan 16, 2018 at 10:23 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> There are cases in which a queued coroutine must be restarted from >> non-coroutine context (with qemu_co_enter_next). In this cases, >> qemu_co_enter_next also needs to be thread-safe, but it cannot use a >> CoMutex and so cannot qemu_co_queue_wait. This happens in curl (which >> right now is rolling its own list of Coroutines) and will happen in >> Fam's NVMe driver as well. >> >> This series extracts the idea of a polymorphic lockable object >> from my "scoped lock guard" proposal, and applies it to CoQueue. >> The implementation of QemuLockable is similar to C11 _Generic, but >> redone using the preprocessor and GCC builtins for compatibility. >> >> In general, while a bit on the esoteric side, the functionality used >> to emulate _Generic is fairly old in GCC, and the builtins are already >> used by include/qemu/atomic.h; the series was tested with Fedora 27 (boot >> Damn Small Linux via http) and CentOS 6 (compiled only). >> >> Paolo >> >> v1->v2: fix typos and copyright year > > Reviewed-by: Fam Zheng <f...@redhat.com> > > Should I include this series in my pull request for the NVMe driver?
Yes, please. This is within block layer area, since CoQueue and block/curl.c are still the only users. Paolo
