On Sat, 25 Feb 2012 10:46:07 +0200 Alon Levy <al...@redhat.com> 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<al...@redhat.com> > > > > 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.
