nanogui: nasty client/server bug fix


Previous by date: 1 Dec 2000 18:23:07 -0000 Re: CLPS7500FE chip is slowly, Greg Haerr
Next by date: 1 Dec 2000 18:23:07 -0000 Re: CLPS7500FE chip is slowly, Alan Cox
Previous in thread:
Next in thread: 1 Dec 2000 18:23:07 -0000 Re: nasty client/server bug fix, Morten Rolland

Subject: nasty client/server bug fix
From: "Greg Haerr" ####@####.####
Date: 1 Dec 2000 18:23:07 -0000
Message-Id: <073c01c05bc4$0ff361a0$15320cd0@gregh>

Morten,
    I've finally solved the rare bug that you talked about
previously between Nano-X clients and the server.  This
manifested itself when the server posted a GsError, for
instance, and clients would get out of sync, as well as
when folks used GrGetNextEventTimeout, or GrPrepareSelect.

Another aspect of this nasty bug showed up as the client
Nano-X library used the "if (storedevent)" code that
stored one event (always a GetNextEvent) when it was
looking for another reply.  In the error condition, a second
or more event was stored on top of the previously stored event,
which resulted in events being discarded.

The reason for this is actually quite complicated, but a simple
explanation is that if a GetNextEvent request was sent, but
timed out before getting a response, then the server, if
multiple events were queued and the system was busy,
would write more than one event on the wire.  This caused
the client to overwrite events waiting for the response it
was looking for.

The only solution here is that the client must have a
client-side event queue, so that's what is now implemented.
I believe this completely fixes the problem, without 
a lot of code, as well.

Did you ever fix this problem for the FreePad?

Regards,

Greg




Previous by date: 1 Dec 2000 18:23:07 -0000 Re: CLPS7500FE chip is slowly, Greg Haerr
Next by date: 1 Dec 2000 18:23:07 -0000 Re: CLPS7500FE chip is slowly, Alan Cox
Previous in thread:
Next in thread: 1 Dec 2000 18:23:07 -0000 Re: nasty client/server bug fix, Morten Rolland


Powered by ezmlm-browse 0.20.