On Saturday 13 May 2006 16:15, Chris Wilson wrote: > 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.
Yes, but it's a bidirectional connection. The client doesn't know if the packet it just received was send before or after the server received the SetPixelFormat message. Paul _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
