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

[Gregory Crosswhite]

 On 08/03/10 15:22, Evan Laforge wrote:
> On Tue, Aug 3, 2010 at 3:06 PM, Gregory Crosswhite
> <gcross at phys.washington.edu> wrote:
>> But you've got it backwards:  if the function I am calling can call back
>> into Haskell (i.e., is marked as "safe"), then GHC *doesn't* block the
>> world, but if the function I am calling will never call back into Haskell
>> (i.e., is marked as "unsafe"), then GHC *does* block the world.  The
>> reasoning behind this choice of behaviors is exactly what I do not
>> understand.
> "unsafe" calls are fast but unsafe.  If they call back to haskell, or
> take a long time, bad things will happen.
>
> "safe" calls are safer: They can call back to haskell, block on IO, or
> just wander off and do something CPU intensive.  As is often the case,
> you pay a little bit of efficiency for the safety, since the RTS has
> to line up a few ducks to allow callbacks (and presumably
> concurrency).
>
> Just think of "unsafe" in relation to "unsafeIndex" or something.
> It's faster, but you have to be sure the index is in bounds.
Yes, but the whole reason to use "unsafe" is to get higher performance
at the cost of safety.  If the result of calling an "unsafe" foreign
function is that you *lose* performance because the other threads have
to be halted first, then this seems to defeat the whole point of marking
a call as "unsafe" in the first place.

Cheers,
Greg