From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45579) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra44j-000798-U1 for qemu-devel@nongnu.org; Mon, 12 Dec 2011 06:29:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ra44h-0005g5-B6 for qemu-devel@nongnu.org; Mon, 12 Dec 2011 06:29:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:6112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ra44h-0005fl-4O for qemu-devel@nongnu.org; Mon, 12 Dec 2011 06:29:39 -0500 Message-ID: <4EE5E59C.5030603@redhat.com> Date: Mon, 12 Dec 2011 12:29:32 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <20111208174544.325838a6@doriath> <20111211102915.GB2791@garlic> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Dropping the MONITOR_CMD_ASYNC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Yonit Halperin , qemu-devel , stefanha@linux.vnet.ibm.com, Luiz Capitulino On 12/12/11 11:18, Stefan Hajnoczi wrote: > On Sun, Dec 11, 2011 at 10:29 AM, Alon Levy wrote: >> On Thu, Dec 08, 2011 at 05:45:44PM -0200, Luiz Capitulino wrote: >>> Hi there, >>> >>> I'm about to completely drop the MONITOR_CMD_ASYNC API, but it turns out that >>> the command client_migrate_info uses it. That's a legacy interface and has to >>> be dropped, no command should be using it... >>> >>> Something tells me that if I just drop it (and change the command to use the >>> regular interface), bad things will happen. Am I right? :) >>> >> >> The monitor command client_migrate_info needs to complete after getting >> an ACK message from the currently connected spice client (this is the >> only case where this is required - if there is no client then the >> MONITOR_CMD_ASYNC API won't be used). This in turn requires the main >> thread to perform select and call the callback that will process this >> ACK. That's why the MONITOR_CMD_ASYNC API was used. >> >> I'm not aware of any other way to do this, I'll be glad for any help >> here. Also, I understand this is not what is not true async, since one >> would expect a true async interface to support multiple in flight >> monitor commands. If there is any ETA or existing way to do this we >> could change the implementation of client_migrate_info. > > Is it possible to use a QMP event to signal completion instead of a > MONITOR_CMD_ASYNC command? Problem is this breaks the qemu <-> libvirt interface. cheers, Gerd