What does 'threadsafe' mean?

[Wolfgang Thaller]

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