From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKT0b-0000py-QV for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:11:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKT0W-00079r-WF for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:11:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKT0W-000742-Qq for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:11:00 -0400 References: <20150729150531.GI16847@redhat.com> From: Eric Blake Message-ID: <55B8ECFE.6000707@redhat.com> Date: Wed, 29 Jul 2015 09:10:54 -0600 MIME-Version: 1.0 In-Reply-To: <20150729150531.GI16847@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tHdN2W1p1RDHSge3oopj2kmnwGcigklrS" Subject: Re: [Qemu-devel] RFC: async commands with QMP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , =?UTF-8?Q?Marc-Andr=c3=a9_Lureau?= Cc: QEMU This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tHdN2W1p1RDHSge3oopj2kmnwGcigklrS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: >> >=20 > 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. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --tHdN2W1p1RDHSge3oopj2kmnwGcigklrS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVuOz+AAoJEKeha0olJ0Nq250H/0BP+fPHVusp7m7Y0swyIhwv +hPEJT6loVTN1kBOV11K07GPGHrtjbeizcEY7hYISDnchtXbAubYKwLISUe3oXOR ZT+OXigNawt0k4WyOkU1E44qHppTXrKR5r56Hd9/OHSQuEzbtPEAlPwcGT1k77jj AtyCrAlp0/C9Xs5s5CwhVWyacT5IkC5zFVEwvntwzMgyRLgFVVfPPP1Fz2j0q+LZ ggj1M6EG94W3wv+aEqEy9mpMhsDw9KA4HAPZ1ceCyg9Ib2IMhnA0lcpeyBTYdhAO uJX9vtyBFV53dlOyewlP8/Sd96L7meWwN1mhRl4O81hl1BpjsN/ExYnzStDRXN0= =oFMU -----END PGP SIGNATURE----- --tHdN2W1p1RDHSge3oopj2kmnwGcigklrS--