[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 1/4] qapi: Add a 'coroutine' flag for commands
From: |
Markus Armbruster |
Subject: |
Re: [PATCH v4 1/4] qapi: Add a 'coroutine' flag for commands |
Date: |
Wed, 22 Jan 2020 13:15:06 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Kevin Wolf <address@hidden> writes:
> Am 22.01.2020 um 07:32 hat Markus Armbruster geschrieben:
>> Kevin Wolf <address@hidden> 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?