nanogui: Corrupted Packet Nano-X
Subject:
Re: [nanogui] Re: Corrupted Packet Nano-X
From:
"Aaron J. Grier" ####@####.####
Date:
18 Sep 2007 19:38:22 +0100
Message-Id: <20070918180923.GA22492@mordor.unix.fryenet>
On Wed, Sep 12, 2007 at 02:24:25PM -0600, Greg Haerr wrote:
> > 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.)
>
> Yes, I'd like to see that code. (actually you may have sent it some
> time ago, this sounds familiar). However, since THREADSAFE wraps all
> Gr functions, what's the difference with your approach?
>
> The current THREADSAFE implementation uses the same lock around all Gr
> calls, including client server read calls, so the above shouldn't be
> an issue, right?
after studying the code for a couple days, you're correct... my old
big-lock code (attached) should be equivalent to the use of SERVER_LOCK
with LINK_APP_INTO_SERVER.
> The corrupted packet has to do with a sync issue that arises when a
> non-void GrXXX call reads the pipe to get its return data, but gets an
> out-of-sync event from the server instead.
clients have to hold a lock to send a request to the server, and don't
release it until they read back any necessary response. the server is
single-threaded, and only handles one request at a time. what am I
missing?
--
Aaron J. Grier | Frye Electronics, Tigard, OR | ####@####.####
