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

[Gregory Crosswhite]

 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.

Cheers,
Greg

On 08/03/10 14:58, Daniel Peebles wrote:
> It's a matter of perspective. Either the function you're FFI'ing to is
> safe/unsafe or your use of it is safe/unsafe. The FFI spec seems to be
> using the former, so if you think that the function you're calling is
> unsafe (i.e., can call back into Haskell) then it blocks the world.
>
> But I do think it's unintuitive and a less ambiguous naming scheme
> would be nicer.
> Dan
>
> On Tue, Aug 3, 2010 at 11:54 PM, Gregory Crosswhite
> <gcross at phys.washington.edu <mailto:gcross at phys.washington.edu>> wrote:
>
>      Hey everyone,
>
>     Could someone explain to me the logic behind having "unsafe" calls
>     block
>     other threads from executing?  It seems to me that if anything it
>     would
>     make more sense for "safe" calls to block other threads since the call
>     can call back into the Haskell runtime, as opposed to "unsafe" calls
>     which (by assertion) will never call back into Haskell and therefore
>     should be safer to run in parallel with other threads.  What am I
>     missing here?
>
>     Cheers,
>     Greg
>     _______________________________________________
>     Haskell-Cafe mailing list
>     Haskell-Cafe at haskell.org <mailto:Haskell-Cafe at haskell.org>
>     http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100803/4f877180/attachment.html