Kevin Wolf <kw...@redhat.com> writes: > Am 22.01.2020 um 07:32 hat Markus Armbruster geschrieben: >> Kevin Wolf <kw...@redhat.com> writes: >> >> > This patch adds a new 'coroutine' flag to QMP command definitions that >> > tells the QMP dispatcher that the command handler is safe to be run in a >> > coroutine. >> >> I'm afraid I missed this question in my review of v3: when is a handler >> *not* safe to be run in a coroutine? > > That's a hard one to answer fully.
You're welcome ;) > Basically, I think the biggest problem is with calling functions that > change their behaviour if run in a coroutine compared to running them > outside of coroutine context. In most cases the differences like having > a nested event loop instead of yielding are just fine, but they are > still subtly different. > > I know this is vague, but I can assure you that problematic cases exist. > I hit one of them with my initial hack that just moved everything into a > coroutine. It was related to graph modifications and bdrv_drain and > resulted in a hang. For the specifics, I would have to try and reproduce > the problem again. Interesting. Is coroutine-incompatible command handler code necessary or accidental? By "necessary" I mean there are (and likely always will be) commands that need to do stuff that cannot or should not be done on coroutine context. "Accidental" is the opposite: coroutine-incompatibility can be regarded as a fixable flaw. How widespread is coroutine-incompatibility? Common, or just a few commands? If coroutine-incompatibility is accidental, then your code to drop out of coroutine context can be regarded as a temporary work-around. Such work-arounds receive a modest extra ugliness & complexity budget. If coroutine-incompatibility is rare, we'll eventually want "mark the known-bad ones with 'coroutine': false" instead of "mark the known-good ones with 'coroutine': true". I'm okay with marking the known-good ones initially, and flipping only later. Inability to recognize coroutine-incompatibility by inspection worries me. Can you think of ways to identify causes other than testing things to death?
