New Bound Threads Proposal

[Dean Herington]

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