Programming

Now I'm following you. GTK being single-threaded would simplify this, no? Plug the event queue with a mutex and you know it won't be using that data until you unlock it.

Still, though -- you probably shouldn't call GTK calls from anything but the thread you initialized GTK with.

I still don't understand how you expect Xt to "protect their data" from things reaching in and modifying it without notification. It takes two to tango. Mutexes and memory barriers have no purpose for things that don't create their own threads.

I suppose I shouldn't have assumed Xt would mutex protect its data...just sort of wishful thinking. Prior to my having access to the Xt/Xm source code (or better, prior to it being released as open source) I had no idea if they did, so figured I'd give it a shot. It wouldn't be hard...but I suppose it also wouldn't be beneficial given that the performance hit it'd constantly take would not be worth taking for the few applications that would need it.

Besides, I suppose I could have always added timers/sockets to Xt's input loop to simulate the "stats gathering" thread. However, for the particular application I was working on at the time, that wasn't possible (the stats gathering thread was really a bunch of threads all querying databases for information, putting those calls in the GUI thread would have led to an awfully sluggish GUI). I hated using a pipe for something as simple as a trigger, but Xt didn't support testing a Posix message queue ID in the event loop (and I still don't think any other *nix version than AIX has a poll/select that allows it, so since the event loop is based around that, it couldn't even if it wanted to). Anyway....