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 _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
