From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: QEMU <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] RFC: async commands with QMP
Date: Mon, 14 Sep 2015 18:01:31 +0200 [thread overview]
Message-ID: <CAJ+F1C+=81TEf2eWmXDMf8RCYypyen3DY4sVvahWGeA6=hCBQQ@mail.gmail.com> (raw)
In-Reply-To: <87613dp12b.fsf@blackfin.pond.sub.org>
Hi
On Mon, Sep 14, 2015 at 3:45 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> Querying status is not incompatible with having async commands. It's
>> not because command return immediately that the job is finished, it's
>> async already!
>
> I'm not sure I got your point here. But see below.
I try to explain that we have commands that are async (the monitor
returns nothing but you can later query status and receive events for
completion).
It is useful to start calling them -async, and have a common way to
deal with them, instead of having to create dissociated commands and
events and having each command to implement them in different way
(both on callee and caller side).
>> This proposal is about having a return when the job is
>> actually finished to avoid having to continuously query, that's the
>> main motivation. Today's return for async commands is pretty useless,
>> you can admit, it's just a ack that the command got accepted and
>> eventually started...
>
> Let's step back and consider the general life cycle of a "job". I'm
> calling it "job" to distinguish it from "QMP command".
>
> User orders a job to get done
>
> System either accepts or rejects the job
> if reject, we're done
>
> Job runs for a while, then either fails or succeeds
>
> Anthony's initial QMP design wanted this wrapped in QMP as follows:
>
> User sends a QMP command
> If we reject the job, send a QMP error response
> Else, the job runs until it fails or succeeds
> when it fails, send a QMP error response
> when it succeeds, send a QMP success response
>
> The idea was that *all* commands are asynchronous! However, the initial
> implementation was in fact completely synchronous.
>
> For most jobs, the "while" in "runs for a while" is reliably very short,
> so this wasn't a problem. When the first job was added where that isn't
> the case, the implementation was hacked up to support asynchronous
> commands. However, we didn't change the existing commands to become
> asynchronous then. Probably because we were pushing very hard to get
> QMP reasonably complete, so clients can migrate off HMP. In retrospect,
> that was probably the last chance to go back the original design,
> because from then on, commands being synchronous became ABI real quick.
> Asynchronous commands remained a freaky exception, and we never even
> bothered to fix its bugs.
>
> Instead, we went down a different route: we used QMP events to signal
> job completion. Events already existed, so this was natural. Jobs
> become wrapped in QMP as follows:
>
> User sends a QMP command
> If we reject the job, send a QMP error response
> Else, send a QMP success response
> now the job runs until it fails or succeeds
> in either case, send a QMP event
>
> For the event to make sense, the initial command usually needs to
> establish a suitable job ID.
>
> Now let's refine the life cycle some: clients want to query job status,
> and cancel jobs.
>
> The synchronous commands + events design can support it easily. Simply
> have a command to query status, taking the job ID as argument.
> Likewise, have a command to cancel. Both are synchronous. Cancel may
> fail (say because the job has completed meanwhile).
>
> The asynchronous command design could support it as well, with one
> problem: we need a job ID. The QMP command ID is no good, because it's
> tied to a connection, while a job ID must remain valid as long as the
> job runs. Solvable.
>
> So yes, "querying status is not incompatible with having async
> commands".
>
> My point is: asynchronous commands vs. synchronous commands + events
> appears to be a wash: both get the job done. For better or worse, we
> have the latter working, but not the former. Why should we add the
> former now?
If you think about it, the caller already has to deal with unexpected messages:
1)
Caller send QMP command
Caller may receive unrelated QMP event (repeat)
Caller receives QMP return
With async commands today, this is how it goes:
2)
Caller send QMP async command id "foo"
Caller may receive unrelated QMP event (repeat)
Caller receives QMP return
Caller may receive unrelated QMP event (repeat)
Caller receives QMP event for "foo" completion
After all an event is just a message, why not let this message be a
regular "return" for the caller then?
3)
Caller send QMP async command id "foo"
Caller may receive unrelated QMP event (repeat)
Caller receives QMP return for "foo"
There is no big difference with 2). Here the return is associated with
the command, there is no need for an initial "return" and no need to
come up with a new event for completion. The event isn't broadcasted
to all listeners.
So it's not so much about introducing async, but rather providing
helpers to help deal with async commands. Events are not well
associated with commands in the API and they are better for broadcast
than to reply from command. The resulting QAPI isn't actually changed:
But callers should opt-in because return may come out of order and
that's similar to events for return today.
--
Marc-André Lureau
prev parent reply other threads:[~2015-09-14 16:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-29 14:49 [Qemu-devel] RFC: async commands with QMP Marc-André Lureau
2015-07-29 14:51 ` Marc-André Lureau
2015-07-29 15:05 ` Daniel P. Berrange
2015-07-29 15:10 ` Eric Blake
2015-07-29 15:32 ` Marc-André Lureau
2015-07-29 15:45 ` Daniel P. Berrange
2015-07-29 15:18 ` Marc-André Lureau
2015-09-14 13:45 ` Markus Armbruster
2015-09-14 16:01 ` Marc-André Lureau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJ+F1C+=81TEf2eWmXDMf8RCYypyen3DY4sVvahWGeA6=hCBQQ@mail.gmail.com' \
--to=marcandre.lureau@gmail.com \
--cc=armbru@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.