safe and threadsafe

[Simon Peyton-Jones]

| *) 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