safe and threadsafe

Simon Peyton-Jones simonpj at
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
be concurrent?   


More information about the FFI mailing list