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.


Qemu-devel mailing list

Reply via email to