[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] RFC: async commands with QMP
From: |
Marc-André Lureau |
Subject: |
[Qemu-devel] RFC: async commands with QMP |
Date: |
Wed, 29 Jul 2015 16:49:56 +0200 |
Hi
It seems there is no support for async commands with QAPI/QMP other
than having to poll for status, or a "sync" command followed
eventually by an event. But, there is no direct relation between the
command and the event.
As a monitor command shouldn't block, it would be useful to have async
commands support, if possible with a common scheme.
Here is a simple proposal, let's take an existing command:
-> { "execute": "drive-backup", "arguments": {
"device": "drive0",
"sync": "full",
"target": "backup.img" },
"id": 1234 }
<- { "return": {}, "id": 1234 }
You can then check regularly the state with query-block-jobs.. Suppose
instead of returning immediately, a similar function would return when
the task is completed. It would be nice if you wouldn't have to
duplicate existing blocking functions to an _async variant. Could we
introduce an additional "async" member? (rightfully rejected on qemu
today)
-> { "execute": "drive-backup", "arguments": {
"device": "drive0",
"sync": "full",
"target": "backup.img" },
"id": 1234,
"async": true }
Here, with "async": true, the caller knows he shouldn't expect an
immediate return, and he can exchange other messages:
-> { "execute"...
<- { "event", ...
And when "drive-backup" finishes:
<- { "return": {}, "id": 1234 }
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:
-> { "execute": "drive-backup-async", "arguments": {
"device": "drive0",
"sync": "full",
"target": "backup.img" },
"id": 1234 }
<- { "return-async": {}, "async_id": 42 }
... later on:
<- {"event": "ASYNC_COMPLETED", "async_id": 42,
"data": {.return values could go there..}, "id" 1234}
I haven't looked much on the implementation side, but I can try to
implement a proof-of-concept. Let see if this threads brings some
discussion first.
cheers
--
Marc-André Lureau
- [Qemu-devel] RFC: async commands with QMP,
Marc-André Lureau <=