Re: gnome-boxes lockup issue

[Alexander Larsson <alexl redhat com>]

On Wed, 2012-05-09 at 10:47 +0100, Daniel P. Berrange wrote:

> Urgh, ultimately I think this is a serious SPICE server flaw. The
> spice thread in QEMU must not block itself waiting for the SPICE
> client todo something. If it really must block itself, then it must
> absolutely never block the rest of the QEMU process by holding locks.

Blocking the guest from doing progress and producing lots more graphics
calls when the client can't keep up is currently how the spice server
handles rate limiting to the client.

I think this has to change though, it doesn't seem to scale to a
multi-client spice setup. We should be filling the client pipe buffer
with data at full rate, and when it is full we should start merging
operations on the server side (i.e. so that the client doesn't see every
step in a smooth animation). 

Of course, that might be problematic for guest apps that draw "as fast
as possible" to the hardware, without syncing to e.g. the refresh rate,
as it will cause a lot more graphics operations than with a regular
hardware where each drawing operation actually takes some time depending
on the hardware and the size of the request, so maybe we have to have
*some* delays in the system when the client is not keeping up.