[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] VNC display support for QEMU
Date: Sun, 30 Apr 2006 15:14:02 -0500
User-agent: Mail/News 1.5 (X11/20060309)

Johannes Schindelin wrote:

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.


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.


Qemu-devel mailing list

reply via email to

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