[Haskell-cafe] Why do "unsafe" foreign calls block other threads?
illissius at gmail.com
Wed Aug 4 06:36:44 EDT 2010
On Wed, Aug 4, 2010 at 1:50 AM, Donn Cave <donn at avvanta.com> wrote:
> 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.)
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:
As for the specific question, callbacks do happen concurrently.
> Donn Cave, donn at avvanta.com
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
Work is punishment for failing to procrastinate effectively.
More information about the Haskell-Cafe