* Daniel P. Berrange (berra...@redhat.com) wrote: > On Wed, Sep 06, 2017 at 12:31:58PM +0100, Dr. David Alan Gilbert wrote: > > * Daniel P. Berrange (berra...@redhat.com) wrote: > > > This does imply that you need a separate monitor I/O processing, from the > > > command execution thread, but I see no need for all commands to suddenly > > > become async. Just allowing interleaved replies is sufficient from the > > > POV of the protocol definition. This interleaving is easy to handle from > > > the client POV - just requires a unique 'serial' in the request by the > > > client, that is copied into the reply by QEMU. > > > > OK, so for that we can just take Marc-André's syntax and call it 'id': > > https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03634.html > > > > then it's upto the caller to ensure those id's are unique. > > Libvirt has in fact generated a unique 'id' for every monitor command > since day 1 of supporting QMP. > > > I do worry about two things: > > a) With this the caller doesn't really know which commands could be > > in parallel - for example if we've got a recovery command that's > > executed by this non-locking thread that's OK, we expect that > > to be doable in parallel. If in the future though we do > > what you initially suggested and have a bunch of commands get > > routed to the migration thread (say) then those would suddenly > > operate in parallel with other commands that we're previously > > synchronous. > > We could still have an opt-in for async commands. eg default to executing > all commands in the main thread, unless the client issues an explicit > "make it async" command, to switch to allowing the migration thread to > process it async. > > { "execute": "qmp_allow_async", > "data": { "commands": [ > "migrate_cancel", > ] } } > > > { "return": { "commands": [ > "migrate_cancel", > ] } } > > The server response contains the subset of commands from the request > for which async is supported. > > That gives good negotiation ability going forward as we incrementally > support async on more commands.
Is that 'qmp_allow_async' a command purely to query whether a command is async or is it a wrapper to cause that command to be executed async? > > b) I still worry how the various IO channels will behave on another > > thread. But that's more a general feeling rather than anything > > specific. > > The only complexity will be around making sure the Chardev code uses > the right GMainContext for any watches on the underlying QIOChannel, > so that we poll() from the custom thread instead of the main thread. > IOW, as long as all I/O is done from the single thread everything > should work fine. Dave > Regards, > Daniel > -- > |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o- https://fstop138.berrange.com :| > |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
