FFI, safe vs unsafe
wolfgang.thaller at gmx.net
Wed Apr 12 12:07:06 EDT 2006
Simon Marlow wrote:
> I agree. So other suggestions? longrunning? mightblock or mayblock?
I don't like "*block", because the question of blocking is irrelevant
to this issue. It's about whether the foreign call returns sooner or
later, not about whether it spends the time until then blocked or
Personally, I'm still in favour of inverting this. We are not in
court here, so every foreign function is guilty until proven
innocent. Every foreign function might be "longrunning" unless the
programmer happens to know otherwise. So maybe... "returnsquickly"?
As far as I can gather, there are two arguments *against* making
longrunning/concurrent the default:
1) It's not needed often, and it might be inefficient.
2) There might be implementations that don't support it at all (I
might have convinced John that everyone should support it though..).
3) There might be implementations where concurrent calls run on a
different thread than nonconcurrent calls.
Now I don't buy argument 1; For me the safety/expected behaviour/easy
for beginners argument easily trumps the performance argument.
ad 3). For implementations that don't support Bound Threads, John
Meacham proposed saying that nonconcurrent calls are guaranteed to be
executed on the main OS thread, but no guarantees where made about
concurrent calls; that makes a lot of sense implementation-wise.
However, this means that calls to the main loops for GLUT, Carbon and
Cocoa (and maybe others) have to be annotated
"nonconcurrent"/"returnsquickly" despite the fact that they return
only after a long time, just to keep access to the right thread-local
state. I see a big fat #ifdef heading our way.
More information about the Haskell-prime