nanogui: Corrupted Packet Nano-X
Subject:
Re: Corrupted Packet Nano-X
From:
"Aaron J. Grier" ####@####.####
Date:
12 Sep 2007 19:44:53 +0100
Message-Id: <20070912184437.GS22036@mordor.unix.fryenet>
On Wed, Sep 12, 2007 at 12:18:39AM -0600, Greg Haerr wrote:
> 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.
I've also run into this problem since trying our app with client/server.
I have previously been using a "big lock" approach with our
multithreaded application, replacing _all_ nano-X calls with mutex
wrappers via link-time magic. (it was implemented a couple years before
the THREADSAFE option appeared in nano-X.) the big lock has proven
reliable (we have shipped hundreds of instruments since late 2003 and
never run into this problem) but it does mean there is some risk of
denial-of-service / priority inversion since a lower priority thread
could potentially starve out a higher one by making repeated graphics
calls.
I'm wondering if a simpler more appropriate fix would be to put a lock
on the client read side for server responses. I'll cook something up
and see how it works. otherwise I'll dust off our big lock code. (if
anybody's interested, I'll post it to the list. it is GNU-specific.)
--
Aaron J. Grier | Frye Electronics, Tigard, OR | ####@####.####
