Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type

[Marc-André Lureau]

Hi

On Mon, May 27, 2019 at 3:23 PM Markus Armbruster <address@hidden> wrote:
>
> Gerd Hoffmann <address@hidden> writes:
>
> > On Mon, May 27, 2019 at 10:18:42AM +0200, Markus Armbruster wrote:
> >> Marc-André Lureau <address@hidden> writes:
> >>
> >> > Hi
> >> >
> >> > On Thu, May 23, 2019 at 9:52 AM Markus Armbruster <address@hidden> wrote:
> >> >> I'm not sure how asynchronous commands could support reconnect and
> >> >> resume.
> >> >
> >> > The same way as current commands, including job commands.
> >>
> >> Consider the following scenario: a management application such as
> >> libvirt starts a long-running task with the intent to monitor it until
> >> it finishes.  Half-way through, the management application needs to
> >> disconnect and reconnect for some reason (systemctl restart, or crash &
> >> recover, or whatever).
> >>
> >> If the long-running task is a job, the management application can resume
> >> after reconnect: the job's ID is as valid as it was before, and the
> >> commands to query and control the job work as before.
> >>
> >> What if it's and asynchronous command?
> >
> > This is not meant for some long-running job which you have to manage.
> >
> > Allowing commands being asynchronous makes sense for things which (a)
> > typically don't take long, and (b) don't need any management.
> >
> > So, if the connection goes down the job is simply canceled, and after
> > reconnecting the management can simply send the same command again.
>
> Is this worth its own infrastructure?

Yes, not having to change/break the client side API is worth some effort.

> Would you hazard a guess on how many commands can take long enough to
> demand a conversion to asynchronous, yet not need any management?

Some of the currently synchronous commands that are doing some
substantial task (many of them are not simply reading values from
memory) could be gradually converted, as needed.

> >> > Whenever we can solve things on qemu side, I would rather not
> >> > deprecate current API.
> >>
> >> Making a synchronous command asynchronous definitely changes API.
> >
> > Inside qemu yes, sure.  But for the QMP client nothing changes.
>
> Command replies can arrive out of order, can't they?

They are returned in order, see "QmpSession: return orderly".


-- 
Marc-André Lureau