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 > <gcr...@phys.washington.edu <mailto:gcr...@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 > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe