nanogui: Problems with flushing the request buffer
Subject:
Re: [nanogui] Problems with flushing the request buffer
From:
"Greg Haerr" ####@####.####
Date:
10 Nov 2007 22:38:00 +0000
Message-Id: <04da01c823ea$52699630$6401a8c0@winXP>
: The problem is that there are situations when the socket interface is
: not empty, but loaded with events from the server. The first byte of
: the next event will be consumed by this code, and BOOM - the event
: handling complains about wrong event types.
Agreed.
:
: I have tried to cure this problem, but have not succeeded. This design
: seems to be fishy and broken.
This code was contributed some time ago. I agree its broken.
The same issue was fixed for the normal code path reading
a function return code with an event at the head of the queue,
and is in the function client.c::CheckBlockType(). This
same mechanism will have to be used here, where if a reply
is requested, the character read is compared to GrNumGetNextEvent
and any event read is queued, in a while loop. The
CheckBlockType function itself could almost be used, except
we need to exit when either a 0 or 1 is returned. I would
recommend keeping in the EPRINTF error to let it be known
when a sync error occurs.
If you get this working, please send a patch.
:
: Is there a solution to this problem? And is it only me having this
: problem? Any experience with shared memory support?
Looks like not too many folks are using shared memory...?
Regards
Greg
