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@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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe