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

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