safe and threadsafe

Wolfgang Thaller wolfgang.thaller at
Tue Feb 4 07:24:32 EST 2003

Hello Everyone,

I have recently spent some time improving GHC's support for 
"threadsafe" foreign calls.
As  a side effect of fixing a crashing bug, I made "safe" behave in 
exactly the same way
as "threadsafe". Now I have to document it... :-(
I'm not very happy with the current definition of safety levels in the 
FFI addendum
(section 3.3, Import Declarations). So before I write up somethhing for 
the GHC user manual
explaining how GHC interprets it and why it does so, I'll try to 
convince someone to change
or at least clarify the FFI spec a bit:

First, some things that are unclear:

Are safe calls _guaranteed_ to block all other haskell threads and 
prevent garbage collection,
or is that an implementation detail? Are unsafe calls guaranteed to do 
so? {In a SMP implementation,
this might require additional interthread messaging}.
What should happen when C code running in a separate OS thread calls a 
foreign exported
function while the Haskell Runtime is blocked on a safe call?

Some more points:

In what way can a "safe" call be considered safe in a multithreaded 
environment? After all
it may cause very hard-to-predict blocking. I think that "threadsafe" 
should be the default,
where available.

It _may_ be possible to implement "safe" in a way that is slightly more 
efficient than "threadsafe",
however this is relatively hard to do correctly in the context of GHC, 
and I don't expect a big
performance gain. But if that is possible, then "safe" would be just a 
hint for increasing performance
by sacrificing some "safety". It should be renamed to something else. 
"Ceterum censeo" that
"threadsafe" should be the default.

Some people have said that "safe" calls are intended for serializing 
access to foreign libraries
that are not multithread-safe. I think that MVars should be used for 
such purposes. Blocking the
entire Haskell Runtime for the duration of a "safe" call is overkill, 
but it's not always enough:
Many old C libraries keep state in global variables from one call to 
the next.



ceterum censeo invocationes "tutas" esse delendas.

More information about the FFI mailing list