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. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
