Re: [Qemu-devel] [PATCH] VNC display support for QEMU

[Anthony Liguori <anthony@codemonkey.ws>]

Johannes Schindelin wrote:
> Hi,
>
> On Sat, 29 Apr 2006, Anthony Liguori wrote:
>
>   
>> I would have been more inclined to use LibVNCServer if it wasn't based 
>> on threading.  I really wanted an asynchronous implementation of a VNC 
>> server that didn't depend on threads.
>>     
>
> AFAICT it does not. In vnc_refresh(), there is a call to rfbProcessEvents, 
> which says to select() the socket(s) for 0 microseconds. Same thread.
>   

There is a fundamental design in the LibVNCServer code (which I believe 
was inherited from the various RealVNC derivatives) that all IO is done 
through some derivation of rfbReadExact.  rfbReadExact is semantically 
synchronous (it uses select to enforce that).

You could, perhaps, not begin an iteration of the server message process 
loop until the socket becomes readable but that only gives you a 
semi-asynchronous interface.  As soon as you get 1 byte of message data, 
you are now handling things synchronously until that message is complete.

Since QEMU is single threaded, this means everything blocks (including 
progress of the guest).  This theoretical problem is why I implemented a 
true asynchronous VNC implementation.  You'll notice that I use a state 
machine to handle the message dispatch (which is practical for the 
server side of the VNC protocol at least).  My VNC will never (assuming 
it's working correctly :-)) block guest progress because of outstanding IO.

There is a practical problem too with a semi-asynchronous approach.  
It's entirely possible to get serious congestion in odd places during a 
message transmission (or even a loss that requires timeout).  This means 
you could end up blocking the guest for a prolonged period of time (and 
if the guest is doing serious work--like hosting some sort of network 
service--this is catastrophic).

So, in a multithreaded application or a single-threaded application that 
doesn't have to worry about these things, LibVNCServer is a great 
solution.  I just don't think it's the right solution for QEMU for the 
reasons outlined above.

Regards,

Anthony Liguori

> Now, there is a facility in LibVNCServer to take advantage of pthreads, 
> and in some applications it is actually better to run a background thread 
> to handle all the VNC stuff. But it is not used in QEmu.
>
> Ciao,
> Dscho
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>