Bound Threads

[Simon Marlow]

> I have just spend some time reading through all the 
> discussions and the
> new "threads" document and I would like to propose the 
> addition of a new library function.
> 
> > forkOS :: IO () -> IO ThreadID
> 
> The function "forkOS" forks a new Haskell thread that runs in 
> a new OS (or
> native) thread. With this, I also propose that "forkIO" 
> always runs a Haskell thread in the same OS thread that the 
> current Haskell thread runs in.
> (i.e. "forkIO": same OS thread, "forkOS": new OS thread)

I'd like to point out a concept that I think is being missed here:

   We never want to specify what OS thread is running a particular
   Haskell thread.

why not?  Because (a) it doesn't matter: the programmer can never tell,
and (b) we want to give the implementation freedom to spread Haskell
threads across multiple OS threads to make use of multiple real CPUs.

But the programmer CAN tell, you scream!  How can the programmer tell?
Only by calling foreign functions.  The point is that you want to
specify which OS thread is used to invoke a foreign function, NOT which
OS thread is used to execute Haskell code.  The semantics that Simon & I
wrote make this clear.

If we keep thinking like this, then implementations like Hugs can be
single-threaded internally but switch OS threads to call out to foreign
functions, and implementations like GHC can be multi-threaded internally
and avoid switching threads when calling out to foreign functions.

> Using the new primitive, we can view the new "threadsafe" keyword as
> syntactic sugar:
> 
> > foreign import threadsafe foo :: Int -> IO Int
> 
> ===>
> 
> > foo :: Int -> IO Int
> > foo i = threadSafe (primFoo i)
> >
> > foreign import "foo" primFoo :: IO Int
> 
> where
> 
> > threadSafe :: IO a -> IO a
> > threadSafe io
> > = do result <-newEmptyMVarforkOS (do{ x <-io; putMVar result x })
> > getMVar result

This forces a thread switch when calling a threadsafe foreign function,
which is something I think we want to avoid.  

I'm basing this on two assumptions: (a) switching OS threads is
expensive and (b) threadsafe foreign calls are common.  I could
potentially be wrong on either of these, and I'm prepared to be
persuaded.  But if both (a) and (b) turn out to be true, then worse is
worse in this case.

Cheers,
	Simon