On Sun, Dec 11, 2011 at 10:29 AM, Alon Levy <al...@redhat.com> 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? Stefan
