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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://haskell.org/mailman/listinfo/haskell-prime
