nanogui: Corrupted Packet Nano-X
Subject:
WG: [nanogui] Corrupted Packet Nano-X
From:
"Detzner, Peter" ####@####.####
Date:
12 Sep 2007 07:49:35 +0100
Message-Id: <C68208999FE4B94888BDFF4D9B8CF68CE0F14F@w2kex2.insta.de>
-----Ursprüngliche Nachricht-----
Von: Greg Haerr ####@####.####
Gesendet: Mittwoch, 12. September 2007 08:19
An: Detzner, Peter
Cc: Nanogui List
Betreff: Re: [nanogui] Corrupted Packet Nano-X
> Also, are you running a multithreaded application?
> The Problem appears, when I am trying to do a lot of "focus in" and
> "focus
out". In fact, when I am switching two bitmaps, after a couple of times, it is getting very slow until the "out of memory"/ "corrupted packet" message appears...
The only easy fix to this issue will be to only allow additional threads other than the main original thread to execute void GrXXX functions (that is, typically draw functions) only, and allow ONLY the main thread to execute non-void functions or any function that could require a wait and/or a read from the server. In this way, the THREADSAFE option protects the multiple threads doing write-only client->server operations from stepping on each other in the middle of a request, but the server->client communication is read and processed only by a single thread, the main thread.
BTW, the reason this can't be fixed given the current protocol specification is that there isn't a standard-length reply from the server, and there's only a basic queuing mechanism in the client library. This means that any thread reading the server pipe can't know how many bytes to read, and thus may get interrupted and task switched while in the middle of reading data from the server.
The next thread wakes up, does a read, and gets unexpected crap from the middle of the previous thread's response packet.
Regards,
Greg
