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

[Kevin Wolf]

Am 27.05.2019 um 15:23 hat Markus Armbruster geschrieben:
> 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?
> 
> Would you hazard a guess on how many commands can take long enough to
> demand a conversion to asynchronous, yet not need any management?

Candidates are any commands that perform I/O. You don't want to hold the
BQL while doing I/O. Probably most block layer commands fall into this
category.

In fact, even the commands to start a block job could probably make use
of this infrastructure because they typically do some I/O before
returning success for starting the job.

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

My understanding is that this is just an internal change and commands
still aren't processed in parallel.

Kevin