Alastair Reid wrote:
My reading of the spec is that it means that execution of other runnable Haskell threads and of the foreign function can be interleaved. That is, neither will be 'starved'.
OK. That's about as much as I know. But what does "safe" mean now? If I had never heard of "threadsafe", I never would have thought that a foreign call could block other threads. Is "safe" guaranteed to 'starve' other threads or is it simply allowed to do so? I think this needs to be said explicitly.
Operationally, this requires that the Haskell runtime and the foreign call operate in separate threads.
Not exactly. IIRC, the current GHC implementation executes the foreign call in the same thread that was previously used to execute the Haskell runtime. If "threadsafe" is specified, a new "worker thread" is created that takes over execution of the other Haskell threads until the foreign call finishes in the original thread, at which time control is passed back to the original thread.
I think it is a mistake for the ffi spec to say that single-threaded systems may safely ignore this spec. Who would specify 'threadsafe' if they were not worried about starvation? How could an implementation that allows starvation be considered correct?
I think Haskell compilers that cannot implement 'threadsafe' as it is implemented in GHC should reject Haskell programs which use it. I think the ffi spec should be amended to say this (the spec currently says that such compilers may treat 'threadsafe' as meaning 'safe').
I agree. It should also say whether implementations may treat 'safe' as meaning "threadsafe". Cheers, Wolfgang