It still seems to me that too much "fuss" is being made/proposed over binding or not binding the main Haskell thread to the main OS thread. I remain to be convinced that anything more complicated than "The main Haskell thread is bound to the main OS thread. Period." is justified. Simon Peyton-Jones wrote:
The principal downside is that naïve users might end up with unexpected thread switching for simple concurrent programs.
and Wolfgang Thaller replied:
Yes. (However, for "simple concurrent programs" that cost should be negligible.)
Is it a real concern that a naive user will get significant unexpected overhead? Besides, the example being discussed above, | main = forkIO doLongComputation >> doAnotherLongComputation is unrealistic. Without coordination between the two long computations, if the main thread finishes its `doAnotherLongComputation` before the auxiliary thread finishes its `doLongComputation`, the latter will be summarily abandoned. Simon Peyton-Jones wrote:
So, we could arrange that runMain did the forkIO wrapping above, unless a command line flag said "no, make the main thread bound" in which case we can inject a call to runMain' instead, which refrains from doing a forkIO.
I think it's best to have the runtime system do as little implicit stuff as possible. In particular, it's unattractive for it to fork a Haskell thread (conditionally, no less).
So the proposal boils down to: - yes, at the impl level the main thread is bound, as you suggest - but at the user level, the programmer can control whether or not his 'main' is bound - default is not-bound
If boundedness is not unconditional (as I prefer), I would suggest "bound" as the better default (favoring function over performance). Dean