nanogui: Thread: Problems with flushing the request buffer

Hello All,

I have serious problems with flushing of the request buffer.

I am using uClinux and the PIXIL windowmanager. Shared memory support is 
enabled.

In nxproto.c, there is the following piece of code:

> 			char c;
> 			nxShmCmdsFlushReq req;
>
> 			req.reqType = GrNumShmCmdsFlush;
> 			req.hilength = 0;
> 			req.length = sizeof(req);
> 			req.size = todo;
> 			req.reply = reply_needed;
>
> 			nxWriteSocket((char *)&req,sizeof(req));
>
> 			if ( reply_needed )
> 				while ( read(nxSocket, &c, 1) != 1 )
> 					;
>
> 			reqbuf.bufptr = reqbuf.buffer;

the FLUSH command is sent to the server, and then there is a blocking 
read until the server is sending the response (a single byte "1").

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.

I have tried to cure this problem, but have not succeeded. This design 
seems to be fishy and broken.

Is there a solution to this problem? And is it only me having this 
problem? Any experience with shared memory support?

regards

Amadeus
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

: 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