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? >> >> I'm ignoring "etc" unless you expand it into something specific. >> >> >> >> I'm also not taking the "weird" bait :) >> >> > The following series implements an async command solution instead. By >> >> > introducing a session context and a command return handler, it can: >> >> > - defer the return, allowing the mainloop to reenter >> >> > - return only to the caller (instead of broadcast events for reply) >> >> > - optionnally allow cancellation when the client is gone >> >> > - track on-going qapi command(s) per client/session >> >> > >> >> > and without introduction of new QMP APIs or client visible change. >> >> >> >> What do async commands provide that jobs lack? >> >> >> >> Why do we want both? >> > >> > They are different things, last we discussed it: jobs are geared >> > toward block device operations, >> >> Historical accident. We've discussed using them for non-blocky stuff, >> such as migration. Of course, discussions are cheap, code is what >> counts. > > Using job API means providing new (& more complex) APIs to client. > > The screendump fix here doesn't need new API, it needs new internal > dispatch of QMP commands: the purpose of this series. > > Whenever we can solve things on qemu side, I would rather not > deprecate current API. Making a synchronous command asynchronous definitely changes API. You could still argue the change is easier to handle for QMP clients than a replacement by a job. [...]
