On Fri, Mar 31, 2006 at 03:16:50PM -0500, Wolfgang Thaller wrote:
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.
first of all, a quick note, for GHC, the answers will be "the same thing it does now with -threaded". but I will try to answer with what a simple cooperative system would do.
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?
if 'foo' blocks on a mvar,read,write,etc... then yes.
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?
I am confused, why would anything in particular need to happen at all? the threads are completly independent. The non-concurrent calls could just be haskell code that happens to not contain any pre-emption points for all it cares. in particular, in jhc, non-concurrent foreign imports and exports are just C function calls. no boilerplate at all in either direction. calling an imported foreign function is no different than calling one written in haskell so the fact that threads A and B are calling foregin functions doesn't really change anything.
3.) Same situation as in 1. When 'foo' is called, it forks (using forkIO) a Haskell thread C. How many threads are running now?
3 potentially runable.
4.) Should there be any guarantee about (Haskell) threads not making any progress while another (Haskell) thread is executing a non- concurrent call?
I don't understand why we would need that at all.
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?
He should say just 'reentrant' since concurrent isn't needed for correctness because the tessalation routines are basic calculations and will return. However, on a system like GHC that actually can run code concurrently and actually would have issues enforcing a 'non-concurrent' guarentee it would run concurrently anyway. It would be hard not to on an implementation that supported true OS threads actually. everyone wins. in the absolute worst case there are always #ifdefs but I doubt they will be needed.
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?
it is not that it is hard (well it is sort of), it is just absurdly inefficient and you would have no choice but to pay that price for _every_ foregin export. even when not needed which it mostly won't be. the cost of a foreign export should be a simple 'call' instruction (potentially) when an implementation supports that. the cost of a foreign import concurrent nonreentrant is only paid when actually using such a function, and quite cheap. on linux at least, a single futex, a cached pthread and it gets rolled into the main event loop. so a couple system calls max overhead. John -- John Meacham - ⑆repetae.net⑆john⑈