FFI, safe vs unsafe

[Wolfgang Thaller]

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  
runnning.

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.

Cheers,

Wolfgang