nanogui: Corrupted Packet Nano-X


Previous by date: 12 Sep 2007 21:24:26 +0100 Re: Corrupted Packet Nano-X, Aaron J. Grier
Next by date: 12 Sep 2007 21:24:26 +0100 Japanese fonts with uClinux, Prashanth Dwarakanath
Previous in thread: 12 Sep 2007 21:24:26 +0100 Re: Corrupted Packet Nano-X, Aaron J. Grier
Next in thread: 12 Sep 2007 21:24:26 +0100 Re: Corrupted Packet Nano-X, nanogui.reliableembeddedsystems.com

Subject: Re: [nanogui] Re: Corrupted Packet Nano-X
From: "Greg Haerr" ####@####.####
Date: 12 Sep 2007 21:24:26 +0100
Message-Id: <462d01c7f57a$e9fdfb60$0300a8c0@RDP>

: 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?

Regards,

Greg


Previous by date: 12 Sep 2007 21:24:26 +0100 Re: Corrupted Packet Nano-X, Aaron J. Grier
Next by date: 12 Sep 2007 21:24:26 +0100 Japanese fonts with uClinux, Prashanth Dwarakanath
Previous in thread: 12 Sep 2007 21:24:26 +0100 Re: Corrupted Packet Nano-X, Aaron J. Grier
Next in thread: 12 Sep 2007 21:24:26 +0100 Re: Corrupted Packet Nano-X, nanogui.reliableembeddedsystems.com


Powered by ezmlm-browse 0.20.