Am 27.05.2019 um 15:23 hat Markus Armbruster geschrieben: > Gerd Hoffmann <kra...@redhat.com> writes: > > > On Mon, May 27, 2019 at 10:18:42AM +0200, Markus Armbruster wrote: > >> Marc-André Lureau <marcandre.lur...@gmail.com> writes: > >> > >> > Hi > >> > > >> > On Thu, May 23, 2019 at 9:52 AM Markus Armbruster <arm...@redhat.com> > >> > 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