qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Chris Wilson <chris@qwirx.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Date: Sat, 13 May 2006 15:15:56 +0000 (GMT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0605131508330.11617@localhost> (raw)
In-Reply-To: <446544E3.50208@codemonkey.ws>

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 |

  reply	other threads:[~2006-05-13 15:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-12 12:24 [Qemu-devel] Re: QEMU 0.8.1 and vnc Ben Taylor
2006-05-13  2:30 ` Anthony Liguori
2006-05-13 15:15   ` Chris Wilson [this message]
2006-05-13 15:21     ` Paul Brook
2006-05-13 16:50       ` Anthony Liguori
2006-05-13 19:17         ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2006-05-05 12:24 [Qemu-devel] " Ben Taylor
2006-05-05 14:06 ` [Qemu-devel] " Anthony Liguori
2006-05-12  3:58   ` Troy Benjegerdes
2006-05-12 11:02     ` andrzej zaborowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0605131508330.11617@localhost \
    --to=chris@qwirx.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).