| *) I am not convinced that thread synchronization should be done by the | FFI
Me neither! It was news to me that anyone was *relying* on the (implementation-specific) fact that a "safe" call blocks other Haskell threads. I'd always regarded "safe" as just like "threadsafe" except that it was a bit more efficient, but with the penalty that blocking in the foreign call could gum up all Haskell threads. As Wolfgang says, the atomicity of "safe" is extremely dodgy. I suppose that "unsafe" could also mean "guaranteed atomic". After all, it can't call in, nor do GC, etc. And the RTS is in a state where nothing else can execute anyway. Even then, I agree with Wolfgang that it's very smelly. If you need atomicity, use an MVar, no? You may not want two concurrent GTK calls (although I don't see why not), but a GTK call concurrent with some other I/O would be ok. If two threads are drawing in two different GTK windows, couldn't they be concurrent? simon _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi