tags:

views:

58

answers:

1

I've encountered an interesting problem while developing for our legacy XWindows application.

For reasons that don't bear explaining, I am sending ClientMessage from a comand-line utility to a GUI app.Most of the messages end up having the same contents, as the message's purpose is to trigger a synchronous communication process over some side pipes. I've noticed that some of the time I would send two messages, but only one gets delivered. I've traced this to the fact that both messages had the same contents and were sent in the same second (IOW, the log timestamp on the sending was the same number). As soon as I added some dummy contents to the messages to make them all different, the problem went away.

This happened over two different X servers: vncserver and Exceed. Am I hitting some XWindows feature that I am not aware of - some kind of message throttling/compression? Has anyone encountered this kind of thing?

A: 

The X server should never compress client messages that I'm aware of, but perhaps some X toolkits (Motif, Xaw, etc.) do compress them. That's the first thing I would look for - perhaps the GUI app receiving the message is compressing somewhere inside the toolkit, before the application code sees it.

Then again, both vncserver and exceed probably focus more on remote usage than other X servers, and they could contain some ill-advised compression hacks, conceivably. I have read a lot of X specs and written a lot of X code and never heard of this behavior though.

A random unlikely thought, be sure you have an XFlush() or XSync() at the end of your command line app before it exits, to be sure you write those messages out to the socket before closing down. But I don't know why message content would matter if this is the problem.

Thanks for the answer. The toolkit on X end is Open Interface (AKA Neuron data), God help me. I'll keep my eyes open...
Arkadiy