From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4347AC07542 for ; Mon, 27 May 2019 09:08:39 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1D4A421734 for ; Mon, 27 May 2019 09:08:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D4A421734 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([127.0.0.1]:42343 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVBcU-0006Lj-B9 for qemu-devel@archiver.kernel.org; Mon, 27 May 2019 05:08:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hVBbj-0005xv-69 for qemu-devel@nongnu.org; Mon, 27 May 2019 05:07:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hVBbi-00029B-9Y for qemu-devel@nongnu.org; Mon, 27 May 2019 05:07:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53252) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hVBbi-00024b-51 for qemu-devel@nongnu.org; Mon, 27 May 2019 05:07:50 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 63599883A2; Mon, 27 May 2019 09:07:36 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-116-59.ams2.redhat.com [10.36.116.59]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7DD2A7854F; Mon, 27 May 2019 09:07:32 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 7868C16E1A; Mon, 27 May 2019 11:07:31 +0200 (CEST) Date: Mon, 27 May 2019 11:07:31 +0200 From: Gerd Hoffmann To: Markus Armbruster Message-ID: <20190527090731.uohmamahlg53bu77@sirius.home.kraxel.org> References: <20190409161009.6322-1-marcandre.lureau@redhat.com> <87sgt7sxhy.fsf@dusky.pond.sub.org> <87tvdlhakq.fsf@dusky.pond.sub.org> <87blzo1fa5.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87blzo1fa5.fsf@dusky.pond.sub.org> User-Agent: NeoMutt/20180716 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 27 May 2019 09:07:36 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , Michael Roth , QEMU , "Dr. David Alan Gilbert" , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , John Snow Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, May 27, 2019 at 10:18:42AM +0200, Markus Armbruster wrote: > Marc-Andr=E9 Lureau writes: >=20 > > Hi > > > > On Thu, May 23, 2019 at 9:52 AM Markus Armbruster = wrote: > >> I'm not sure how asynchronous commands could support reconnect and > >> resume. > > > > The same way as current commands, including job commands. >=20 > Consider the following scenario: a management application such as > libvirt starts a long-running task with the intent to monitor it until > it finishes. Half-way through, the management application needs to > disconnect and reconnect for some reason (systemctl restart, or crash & > recover, or whatever). >=20 > If the long-running task is a job, the management application can resum= e > after reconnect: the job's ID is as valid as it was before, and the > commands to query and control the job work as before. >=20 > What if it's and asynchronous command? This is not meant for some long-running job which you have to manage. Allowing commands being asynchronous makes sense for things which (a) typically don't take long, and (b) don't need any management. So, if the connection goes down the job is simply canceled, and after reconnecting the management can simply send the same command again. > > Whenever we can solve things on qemu side, I would rather not > > deprecate current API. >=20 > Making a synchronous command asynchronous definitely changes API. Inside qemu yes, sure. But for the QMP client nothing changes. cheers, Gerd