New Bound Threads Proposal

[Simon Peyton-Jones]

| Does anyone else have objections against always binding the "main"
| Haskell thread to the "main" OS thread?

You make a convincing case.  You don't mention what the disadvantages are.  In an earlier message you say

| If we had
| 
| main = forkIO doLongComputation >> doAnotherLongComputation
| 
| there'd be OS thread switching going on. To optimize that, we'd have to
| write
| 
| main = do
| 	forkIO doLongComputation
| 	mv <- newEmptyMVar
| 	forIO (doAnotherLongComputation >> putMVar mv ())
| 	takeMVar mv

Or, perhaps more uniformly, replace
	main = e
with
	main = do { mv <- newEmptyMVar; forkIO (e >> putMVar mv ()); takeMVar mv }

The principal downside is that naïve users might end up with unexpected thread switching for simple concurrent programs. 


My suggestion would be this.  GHC already injects an extra definition into the Main module, thus

	mainIO = runMain main

where runMain is defined in the library like this
	runMain e = catch e (... report uncaught exceptions ...)
and the runtime system actually invokes mainIO, not main.

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.

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


I think there's enough consensus already to shrink the bound-threads proposal to one proposal with stuff about the main-thread variants.  Would you like to do that Wolfgang?

Incidentally, we're about to fork the tree for GHC 6.0, so I don't think we should aim to get the bound threads into that; but we plan for 6.0 to be a consolidation release, with 6.2 following in a month or two, rather than a year or two.  So aim for 6.2

Simon

| -----Original Message-----
| From: ffi-admin at haskell.org [mailto:ffi-admin at haskell.org] On Behalf Of Wolfgang Thaller
| Sent: 14 May 2003 14:11
| To: ffi at haskell.org
| Subject: Re: New Bound Threads Proposal
| 
| John Meacham wrote:
| 
| > On Tue, May 06, 2003 at 03:19:17PM +0200, Wolfgang Thaller wrote:
| >> 1) bind the "main" Haskell thread to the "main" OS thread
| >> [...]
| > I don't see any problem with 1. It is no worse than the situation in
| > other languages and is significantly better in that Haskell can easily
| > pass around IO actions for the main thread to run. plus, any library
| > documentation for other languages will carry over into Haskell easily.
| 
| Does anyone else have objections against always binding the "main"
| Haskell thread to the "main" OS thread?
| 
| The thing is, if we always make the main thread bound, the
| implementation in the GHC RTS becomes simpler and much more "beautiful".
| 
| Any possible performance penalty due to the use of a bound thread can
| be easily worked around like this:
| 
| main = do
|      finish <- newEmptyMVar
|      forkIO (realMain >> putMVar finish ())
|      takeMVar finish
| 
| <technical details>
| A non-bound "main" thread would be the only non-bound thread that has
| to return somewhere.
| In the previous threaded RTS, this was solved by keeping a global
| variable "mainMainThread"; when that thread ends, the RTS does a
| "threadsafe" foreign call to shutdownHaskellAndExit.
| Also there's that strange distinction between rts_evalLazyIO and
| rts_mainLazyIO in order to avoid spawning another OS thread.
| On program termination, shutdownHaskellAndExit has to make sure that
| there's a second worker thread anyway, because it can't use
| rts_mainLazyIO for executing finalizers.
| 
| All those hacks would go away if the "main" Haskell thread is always
| bound to the "main" IO thread.
| </technical details>
| 
| Cheers,
| 
| Wolfgang
| 
| _______________________________________________
| FFI mailing list
| FFI at haskell.org
| http://www.haskell.org/mailman/listinfo/ffi