On Mon, Feb 20, 2012 at 12:32:44PM +0100, Gerd Hoffmann wrote: > On 02/19/12 22:28, Alon Levy wrote: > > This changes the behavior of the monitor command. After the previous > > patch, there is no longer an option of deadlock with virt-manager, but > > ppm_save is called too early, before the update has completed. With this > > patch it is called at the correct moment, but that means there is a race > > between the monitor command completing and the screendump file being saved. > > > > The only solution is to use an asynchronous monitor command. For a > > previous round of this see: > > http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02810.html > > > > Since that's contentious, I'm suggesting we do something that is almost > > correct and doesn't hang, instead of correct and hangs. The screendump > > user can inotify on the directory and the file if need be. For casual > > monitor usage there is no difference. > > Hmm, that is pretty lame. There are users like autotest which expect > the screen dump being there when the monitor command is finished, that > change will break them. > > Unfortunaly there is no easy way out. I think the options are: > > (1) Keep existing behavior. That means the screenshot might show old > screen content. Not very nice too. Would work sort-of ok for > autotest though as autotest does screenshots every second and thus > the screen content wouldn't be older than a second. > > (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 ... >
I was going to look for QAPI bits after this series (i.e. (2)). Doing (3) is also possible. > cheers, > Gerd >