nanogui: nano-X driver stability discussion
Subject:
RE: nano-X driver stability discussion
From:
Greg Haerr ####@####.####
Date:
20 May 1999 19:34:34 -0000
Message-Id: <01BEA2C5.42B83CA0.greg@censoft.com>
On Thursday, May 20, 1999 1:03 PM, Alex Holden ####@####.#### wrote:
> On Thu, 20 May 1999, Greg Haerr wrote:
> > Okay. I admit I haven't spent too much time playing with the client/server
> > configuration. (Also there was a bug in the GrText() call over the network
> > that I never could figure out)
>
> I had a look at it, and the problem was just that the client wasn't
> reading all the data returned from an earlier call, and that data was
> staying queued in the network buffers, so when it sent the GrText() call,
> it was reading garbage back. Due to the total lack of error handling, the
> server and client both ended up blocked forever in read() as they were
> expecting the other to send them something. The real answer is the total
> rewrite I'm working on now, which does things much closer to the way X
> does it, ie. it packages calls up in a message queue, and sends them all
> at once when the client does a Grflush(), or any call which reads data
> back from the server.
Well I'm glad you figured it out, I couldn't. But the problem that
I saw wasn't a hang bug a crash. The client hangs on reads so it should
never get garbage back, though, right?
Also, another thing I started to change in the client/server code,
but now you should know... In the first version, the GrSendBlock took
an int, rather than a long for the size parm. In ELKS and other 16-bit systems,
this would fail if say ReadArea were called with more than 256x256 pixels (64k).
Also, write() typically works only with < 64k data, so the internal write
loop also needs recoding...
Greg
