New Bound Threads Proposal

[Manuel M T Chakravarty]

"Simon Peyton-Jones" <simonpj at microsoft.com> wrote,

> | > Yesterday evening I was experimenting with an electronic circuit,
> and
> | > the fumes from the soldering must have entered my brain and
> triggered
> | > something there 
> 
> Strangely enough, Simon and I had actually come up with another variant,
> which I believe is simpler than both the original and Wolfgang's
> proposal.  
> 
> I've updated threads.tex and posted Postscript here
> 	http://research.microsoft.com/~simonpj/tmp/threads.ps

I like this proposal best (of the three in the document).
In particular, it is very simple.

Wolfgang Thaller <wolfgang.thaller at gmx.net> wrote,

> *) It violates requirement #4 "The specification shouldn� explicitly 
> require lightweight �reen�threads
> to exist."
> OK, I wrote that requirement, and I might be the only one who cares.
> But I still think that the existance of lightweight threads should not 
> somehow become a feature of the Haskell language.

Not a feature of Haskell 98, but we are talking about a
concurrency extension anyway.  In fact, I think, we should
have an Addendum that covers all concurrency support
(lighweight and OS threads) in one go.  If anything, this is
only going to make the overall system simpler.

So, IMHO, we should negate your requirement.

> *) Using the system requires a lot of knowledge of the thread 
> allocation issues, as all thread management has to be done manually. 
> Special combinators like nonBlocking will have to be used far more 
> often than the "threadbound" combinator of proposal #2.

The FFI design so far has always tried to provide minimal
extensions.

Cheers,
Manuel