Re: [Qemu-devel] [PATCH v2 00/25] qmp: add async command type

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 04.05.2017 um 21:01 hat Markus Armbruster geschrieben:
>> Now let me take a step back: we need to crack the "jobs" problem anyway.
>> Merging this series now would in a way add another special case of the
>> general case "jobs" before adding the general case.  In other words,
>> create more stuff to unify.
>
> It's actually not obvious to me that both cases should be using the same
> infrastructure. The primary target for jobs as we discussed them in the
> past are true long running operations (and in some common cases even
> indefinitely, until the user stops them), whereas for async commands the
> primary target are "quick, but not that quick" operations.
>
> Today, all jobs have a unique job ID, all of them can be paused, all of
> them send completion/cancellation events, and similar things that make a
> lot of sense for true long running operations, but are either useless
> overhead or can't even be implemented for quick operations. The
> unification would potentially lead to many special cases in the job
> infrastructure to allow e.g. anonymous jobs, jobs that aren't listed in
> query-jobs, jobs that don't accept basic management commands like pause,
> jobs that don't send completion events, etc. Would the (superficially)
> unified infrastructure really be worth the special cases?
>
> Just to be clear, I am not necessarily against unifying these two
> classes of operations in our infrastructure if it makes sense, but they
> seem to be distinct enough that I feel we should have a little more
> arguments for it than just "they are the same anyway".

No, the best degree of sharing between asynchronous commands and jobs is
not obvious, simply because jobs do not exist, yet.  Once they do, we
can figure it out.

>> > The benefits of async commands that can be trade-off depending on the
>> > requirements are:
>> >
>> > 1) allow the command handler to re-enter the main loop if the command
>> > cannot be handled synchronously, or if it is long-lasting. This is
>> > currently not possible and make some bugs such as rhbz#1230527 tricky
>> > (see below) to solve.  Furthermore, many QMP commands do IO and could
>> > be considered 'slow' and blocking today.
>
> In any case, I think we can go forward with this one, right? This should
> be useful work no matter what we end up doing with the external
> interface. I've long wished that QMP handlers could be executed in a
> coroutine and yield while they are doing I/O.
>
>> > 2) allow concurrent commands and events. This mainly implies hanlding
>> > concurrency in qemu and out-of-order replies for the client. As noted
>> > earlier, a good qmp client already has to handle dispatching of
>> > received messages (reply and events).
>
> And it's only this one that should wait for generic jobs.

I think so.  Making synchronous QMP commands block only their QMP
monitor, not the whole main loop would be an implementation detail, not
part of the external interface.