Alastair Reid wrote:
OK. That's about as much as I know.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'.
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.
Not exactly. IIRC, the current GHC implementation executes the foreignOperationally, this requires that the Haskell runtime and the foreign call operate in separate threads.
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 _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
