From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKT7V-0005VG-AF for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:18:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKT7T-0001Zo-11 for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:18:13 -0400 Received: from mail-ob0-x235.google.com ([2607:f8b0:4003:c01::235]:33774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKT7S-0001XV-SL for qemu-devel@nongnu.org; Wed, 29 Jul 2015 11:18:10 -0400 Received: by obdeg2 with SMTP id eg2so9539324obd.0 for ; Wed, 29 Jul 2015 08:18:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20150729150531.GI16847@redhat.com> References: <20150729150531.GI16847@redhat.com> Date: Wed, 29 Jul 2015 17:18:10 +0200 Message-ID: From: =?UTF-8?B?TWFyYy1BbmRyw6kgTHVyZWF1?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" Cc: QEMU Hi Daniel On Wed, Jul 29, 2015 at 5:05 PM, Daniel P. Berrange w= rote: > 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. 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. Thanks for the historic reasons, I ignored that. Querying status is not incompatible with having async commands. It's not because command return immediately that the job is finished, it's async already! This proposal is about having a return when the job is actually finished to avoid having to continuously query, that's the main motivation. Today's return for async commands is pretty useless, you can admit, it's just a ack that the command got accepted and eventually started... Also commands can be tight to the lifecycle of a client. Take memsave or screendump, if you give them a client fd, you actually don't care if the client is gone: there is no need to query about the status of those commands. Instead, they should be cancelled when the client is gone. --=20 Marc-Andr=C3=A9 Lureau