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

On Wed, Aug 4, 2010 at 1:50 AM, Donn Cave wrote:

Quoth John Meacham ,

...

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.)

This is slightly out of date (GHC couldn't multiplex haskell threads onto multiple OS threads at the time, but now does), but basically spells out the situation: http://www.haskell.org/~simonmar/papers/conc-ffi.pdf As for the specific question, callbacks do happen concurrently.

thanks,        Donn Cave, donn@avvanta.com

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Work is punishment for failing to procrastinate effectively.