From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKSgC-0000Il-5V for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:50:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKSg9-0008NY-Mu for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:50:00 -0400 Received: from mail-ob0-x232.google.com ([2607:f8b0:4003:c01::232]:34483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKSg9-0008N9-HU for qemu-devel@nongnu.org; Wed, 29 Jul 2015 10:49:57 -0400 Received: by obre1 with SMTP id e1so8858441obr.1 for ; Wed, 29 Jul 2015 07:49:57 -0700 (PDT) MIME-Version: 1.0 Date: Wed, 29 Jul 2015 16:49:56 +0200 Message-ID: From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] RFC: async commands with QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QEMU 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": "ful= l", "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": "ful= l", "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": "ful= l", "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 --=20 Marc-Andr=C3=A9 Lureau