John Snow <js...@redhat.com> writes: > On 4/27/21 7:11 AM, Vladimir Sementsov-Ogievskiy wrote: >> Hi all! >> It's a simpler alternative for >> "[PATCH v4 0/5] block: add block-dirty-bitmap-populate job" >> <20200902181831.2570048-1-ebl...@redhat.com> >> https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg00978.html >> https://patchew.org/QEMU/20200902181831.2570048-1-ebl...@redhat.com/ >> Since we have "coroutine: true" feature for qmp commands, I think, >> maybe we can merge allocation status to bitmap without bothering with >> new block-job? >> It's an RFC: >> 1. Main question: is it OK as a simple blocking command, even in a >> coroutine mode. It's a lot simpler, and it can be simply used in a >> transaction with other bitmap commands. >> > > Hm, possibly... I did not follow the discussion of coroutine QMP > commands closely to know what the qualifying criteria to use them are. > > (Any wisdom for me here, Markus?)
>From Kevin's cover letter: Some QMP command handlers can block the main loop for a relatively long time, for example because they perform some I/O. This is quite nasty. Allowing such handlers to run in a coroutine where they can yield (and therefore release the BQL) while waiting for an event such as I/O completion solves the problem. Running in a coroutine is not a replacement for jobs. Monitor commands continue to run one after the other, even with multiple monitors. All this does is letting monitor commands yield. Running in a coroutine is opt-in, because we're scared of command code misbehaving in coroutine context[*]. To opt-in, add 'coroutine': true to the command's QAPI schema. Misbehaving command code should be rare. The trouble is finding it. If we had a better handle on that, we could make running in a coroutine opt-out. Watch out for nested event loops. Test thoroughly. Questions? [...] [*] Discussed at some length in patch review: Message-ID: <874kwnvgad....@dusky.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2020-01/msg05015.html