From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZger-0003m4-EG for qemu-devel@nongnu.org; Sun, 11 Dec 2011 05:29:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RZgeq-00089f-B9 for qemu-devel@nongnu.org; Sun, 11 Dec 2011 05:29:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45042) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RZgeq-000893-4X for qemu-devel@nongnu.org; Sun, 11 Dec 2011 05:29:24 -0500 Date: Sun, 11 Dec 2011 12:29:15 +0200 From: Alon Levy Message-ID: <20111211102915.GB2791@garlic> References: <20111208174544.325838a6@doriath> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111208174544.325838a6@doriath> Subject: Re: [Qemu-devel] Dropping the MONITOR_CMD_ASYNC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Yonit Halperin , kraxel@redhat.com, qemu-devel , stefanha@linux.vnet.ibm.com 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. Alon