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.<div>
<br></div><div>But I do think it's unintuitive and a less ambiguous naming scheme would be nicer.</div><div>Dan<br><br><div class="gmail_quote">On Tue, Aug 3, 2010 at 11:54 PM, Gregory Crosswhite <span dir="ltr"><<a href="mailto:gcross@phys.washington.edu">gcross@phys.washington.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Hey everyone,<br>
<br>
Could someone explain to me the logic behind having "unsafe" calls block<br>
other threads from executing? It seems to me that if anything it would<br>
make more sense for "safe" calls to block other threads since the call<br>
can call back into the Haskell runtime, as opposed to "unsafe" calls<br>
which (by assertion) will never call back into Haskell and therefore<br>
should be safer to run in parallel with other threads. What am I<br>
missing here?<br>
<br>
Cheers,<br>
Greg<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>