On 12/11/2011 04: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
Then it's completely broken. CMD_ASYNC is broken and should have been removed a
long time ago.
Unfortunately, we're going to have to remove this command until we can move to
full QAPI. I see this went in through Gerd's tree:
commit edc5cb1a52b2847201acf78b0fba67ab3c2464d5
Author: Yonit Halperin <yhalp...@redhat.com>
Date: Mon Oct 17 10:03:18 2011 +0200
spice: turn client_migrate_info to async
Changes to monitor commands really should at least carry an Acked-by from the
QMP maintainer (Luiz). That would have prevented this from happening.
I'll try to be more diligent about enforcing this in the future.
Regards,
Anthony Liguori
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
