safe and threadsafe
simonpj at microsoft.com
Tue Feb 11 03:52:04 EST 2003
| *) I am not convinced that thread synchronization should be done by
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
More information about the FFI