Hi Anthony,

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 dispatched.

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.

Cheers, Chris.
_ ___ __     _
 / __/ / ,__(_)_  | 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

Reply via email to