: 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
