Re: [Qemu-devel] [RFC 5/7] qxl-render: call ppm_save on callback

[Alon Levy <alevy@redhat.com>]

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   eblake@redhat.com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>