On Fri, 12 May 2006, Anthony Liguori wrote:
A problem arises when the client sends a SetPixelFormat message. There is no
"ack" message from the server so the client has to assume that as soon as it
sends out the message, the server is now using the new pixel format. RealVNC
uses totally synchronous IO routines so in practice, the window for this race
condition is small for them. It definitely can occur though and I've
reproduced it with a normal VNC server.
Since the QEmu VNC code is completely asynchronous, we have a much larger
window where this race can occur. The easiest thing to do is avoid the race
all together and not have your client use SetPixelFormat frequently.
Please forgive my ignorance, but why is there a race condition here? You
have exactly one socket open between client and server. It's a TCP socket
so out-of-order delivery or missing messages is impossible. Presumably the
VNC protocol does not allow you to send a message in the middle of another
one. So at any given time, the process/thread that controls the socket
should know exactly what pixel format it's expected to send messages, at
the time of transmission, based on the last SetPixelFormat that has been
If you have multiple threads encoding messages at the same, then I can see
how one thread could start encoding a block for a particular endianness,
and meanwhile another thread is sending a SetPixelFormat message which
would change the endianness. If that were the case, then you could have
the block sender detect that SetPixelFormat had been sent, at the end of
its encoding process, and start encoding again using the new pixel format.
But surely the virtual graphics card would be the source of both types
of messages, and surely its code runs only in a single thread?
Anything else would seem bizarre to me.
Thanks in advance for enlightenment.
_ ___ __ _
/ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |
Qemu-devel mailing list