qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/4] add qmp screendump-async


From: Luiz Capitulino
Subject: Re: [Qemu-devel] [PATCH 4/4] add qmp screendump-async
Date: Tue, 28 Feb 2012 17:10:39 -0300

On Sat, 25 Feb 2012 10:46:07 +0200
Alon Levy <address@hidden> wrote:

> On Fri, Feb 24, 2012 at 04:40:15PM -0600, Anthony Liguori wrote:
> > On 02/24/2012 03:22 PM, Alon Levy wrote:
> > >This is an across the board change since I wanted to keep the existing
> > >(good imo) single graphic_console_init callback setter, instead of
> > >introducing a new cb that isn't set by it but instead by a second
> > >initialization function.
> > >
> > >Signed-off-by: Alon Levy<address@hidden>
> > 
> > What's the rationale for this?
> 
> There is a hang possible with the current screendump command, qxl, a
> spice client using libvirt and spice-gtk such as virt-viewer /
> remote-viewer, where you have:
> 1. libvirt waiting for screendump to complete
> 2. screendump waiting for spice server thread to render
> 3. spice server thread waiting for spice client to read messages

Which messages?

> 4. spice client == libvirt client, waiting for screendump completion

The way I had understood this problem is that qxl takes a long time to
perform a screen dump, which would cause the global mutex to be held for
a long time. If this is really serious, then a async command for it
makes sense IMO.

Now, the problem you describe above is different and maybe it shouldn't
be solved at QMP level. Can you describe it in more detail?

> > I really don't want a plethora of pseudo-async commands.

Agreed, but this is not supposed to be pseudo-async. If a command returns
immediately and sends an event when it later completes, it's really async.

Besides, we have agreed on adding new command + event for commands that
really need to be async.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]