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

[Kevin Wolf <kwolf@redhat.com>]

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".

> > 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.

Kevin