New Bound Threads Proposal

[Simon Marlow]

> Yesterday evening I was experimenting with an electronic circuit, and 
> the fumes from the soldering must have entered my brain and triggered 
> something there - I've thought up a new proposal, which I like much 
> better than the old one.
> It no longer requires extending the FFI syntax; instead, it uses just 
> one new combinator.
> It can be implemented as efficiently as the previous proposal.
> The proposal is described in detail in the new "Part II" of the 
> haskell-report/ffi/threads.tex document (in CVS).
> For everyone's convenience, I've put up a typesetted version again at:
> 
> http://www.uni-graz.at/imawww/haskell/threads.pdf
> 
> Everyone please tell me what you think.

I've not had the benefit of soldering fumes, but I find whiteboard
markers work quite well ;-)

I think I like it.  Just to clarify: when you fork a new Haskell thread,
it isn't associated with a native thread, right?  (the semantics doesn't
model forkIO, I think it probably should).  If true, that gives us the
important principle that 

  At any one time, there is at most one runnable Haskell thread
  associated with, or bound to, any given native thread.

which is important for reducing the complexity of the implementation.
In an implementation which actually runs the Haskell thread in its bound
native thread (eg. GHC), we can be sure that when we want to switch to
the bound native thread it isn't off doing something else.  Is that the
reason for wanting this property?

Cheers,
	Simon