FFI, safe vs unsafe

[Wolfgang Thaller]

Hi everyone,

Before adding non-concurrent, reentrant calls to the language  
standard, please take some time to think about what that means. If  
you have forkIO'ed multiple threads, things start to interact in  
strange ways. I think this is a can of worms we don't want to open.  
(Or open again. It's still open in GHC's non-threaded RTS, and the  
worms are crawling all over  the place there).

So I'm going to ask a few questions about the semantics of non- 
concurrent reentrant calls, and if people can provide answers that  
don't scare me, I'll concede that they have a place in the language  
standard.

1.) Assume thread A and B are running. Thread A makes a non- 
concurrent, reentrant call to Foreign Lands. The foreign function  
calls a foreign-exported Haskell function 'foo'.
While 'foo' is executing, does thread B resume running?

2.) Assume the same situation as in 1, and assume that the answer to  
1 is yes. While 'foo' is running, (Haskell) thread B makes a non- 
concurrent, reentrant foreign call. The foreign function calls back  
to the foreign-exported Haskell function 'bar'. Because the answer to  
1 was yes, 'foo' will resume executing concurrently with 'bar'.
If 'foo' finishes executing before 'bar' does, what will happen?

3.) Same situation as in 1. When 'foo' is called, it forks (using  
forkIO) a Haskell thread C. How many threads are running now?

4.) Should there be any guarantee about (Haskell) threads not making  
any progress while another (Haskell) thread is executing a non- 
concurrent call?

Two more questions, not related to semantics:

5.) Assume that Haskell Programmer A writes a Haskell library that  
uses some foreign code with callbacks, like for example, the GLU  
Tesselator (comes with OpenGL), or, as a toy example, the C Standard  
Library's qsort function. Should Programmer A specify "concurrent  
reentrant" on his foreign import?
Programmer B will say "please don't", as he wants to use a Haskell  
implementation which doesn't support "concurrent reentrant".  
Programmer C will say "please do", as he wants his application's GUI  
to stay responsive while the library code is executing. So what  
should the poor library programmer A do?

6.) Why do people consider it too hard to do interthread messaging  
for handling a "foreign export" from arbitrary OS threads, when they  
already agree to spend the same effort on interthread messaging for  
handling a "foreign import concurrent"? Are there any problems that I  
am not aware of?


If I am wrong and we should indeed provide non-concurrent reentrant  
calls in a concurrent Haskell system, then I think there should be  
satisfying answers to the above questions...

Cheers,

Wolfgang