On 07/29/2015 09:05 AM, Daniel P. Berrange wrote:
>> In order to make "async" variant possible, "id" would have to be
>> provided and unique. I think the async support should also be
>> announced in the qmp_capabilities. Commands would have to opt-in for
>> async support in the schema. An async return wouldn't be allowed when
>> a blocking command is ongoing.
>>
>> There are many variations possible on the same idea. We could
>> introduce new _async functions instead, and keep the "id"
>> requirements. Or alternatively, an "async_id" could be generated by
>> qemu and returned immediately. Then the reply of the command could be
>> an event instead. Ex:
>>

> 
> When QMP was originally written there was some infrastructure for doing
> async commands, but over time this has all been ripped out because it
> was never really used, complicated the code and didn't work too well
> either. It seems we pretty much settled on the approach that all
> commands should be fast to execute, and where there is a long term
> job being run, we have commands to query its status, cancel it, and
> sometimes events too.

In fact, see commit 65207c59, where we ripped it out with prejudice.


>  One of the benefits of this is that it means
> that libvirt can determine current status of ongoing background jobs
> when it restarts and reconnects to a previously launched QEMU, where
> as an async command approach is tied to the specific monitor connection
> that is open.

And that is a real concern with any new proposal for async commands.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org