[Haskell-cafe] Why do "unsafe" foreign calls block other threads?

Donn Cave donn at avvanta.com
Tue Aug 3 19:50:07 EDT 2010

Quoth John Meacham <john at repetae.net>,

> It is more an accident of ghc's design than anything, the same mechanism
> that allowed threads to call back into the runtime also allowed them to
> be non blocking so the previously used 'safe' and 'unsafe' terms got
> re-used. personally, I really don't like those terms, they are
> non-descriptive in terms of what they actually mean and presuppose a RTS
> similar to ghcs current design. 'reentrant' and 'blocking' which could
> be specified independently would be better and would be more
> future-proof against changes in the RTS or between compilers.

Is the concurrency issue documented somewhere?  What does `non blocking'
mean, and why would it not just always be that way?

In my situation, thread creation and dispatch happens in foreign
library code, and execution in the Haskell runtime happens _only_
via callbacks.  I don't need those callbacks to compute in parallel,
generally, but it would be disappointing to hear that a callback
strictly blocks execution of any others for its entire duration,
for example even during a potentially slow I/O.

(Will test for that, but not sure whether it would be conclusive
since the system seems to be slightly broken at this point - need
to disable RTS timer signals ( -V0 ) to survive externally generated
thread dispatch events.)

	Donn Cave, donn at avvanta.com

More information about the Haskell-Cafe mailing list