On Tue, Feb 21, 2012 at 09:15:45AM -0700, Eric Blake wrote: > On 02/21/2012 01:19 AM, Alon Levy wrote: > > >>> (2) Async monitor command. Keeps interface and works nicely. A bunch > >>> of QAPI bits tickled into master meanwhile, so we could look at > >>> this again. Luiz? What is the status here? > >>> > >>> (3) Something like this patch + additionally introduce a > >>> "your-screenshot-is-finished-now" qmp event. Will break existing > >>> users too. But at least they can be adapted without requiring > >>> some external, nonportable service like inotify ... > >> > >> Libvirt would want 3) - any command that becomes async also needs an > >> event to tell us when the command is completed, so that libvirt can > >> maintain the synchronous interface to the user (and/or expose a new flag > >> to allow the user to also benefit from the asynchronous command). > > > > If I do 2) then libvirt won't notice because the monitor command will > > block as usual. Only change would be internal, qemu would continue > > processing other fds in the interim. > > I guess I misunderstood things then. I was assuming that an async > monitor command would mean that the monitor command would return control > to libvirt prior to the screenshot file being completely written; but > libvirt promises a synchronous interface to callers (that is, a caller > using virDomainScreenshot won't get a response until the screenshot file > has started streaming, but that means the file had better be consistent, > and not something that gets modified after libvirt has streamed it to > the caller). I don't particularly care which solution we have, as long > as the overall result is still something where libvirt has guarantees > that the complete screenshot file is available before libvirt then hands > control of that file back to the caller.
Yes, that's the misunderstanding I think everyone is liable to have because it is called "Asyncronous", but in actuallity the implementation of an async monitor command is just what I mentioned: internal to qemu the main thread select loop continuous to run until a callback completes the monitor command. The monitor is suspended during that time, so no change to the monitor user (i.e. libvirt) is visible. Luiz said that this interface is going to be dropped, so we don't want to introduce another user to it now. So the question becomes if there is something equivalent. I totally agree the name "async monitor" should be resereved for the behavior you describe above, and not for the one I just described. In that case there may still be room for an improvement to the monitor commands, maybe only selectively used to not force a lot of code churn, that will allow any command that requires some long computation / operation to take place before returning to the caller (synchronously from it's point of view), while still being responsive by handling any other callbacks that have nothing to do with the monitor in the mean time. Something identical in practice to what is correcntly called "async monitor". > > -- > Eric Blake ebl...@redhat.com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org >