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
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
