New Bound Threads Proposal

[Wolfgang Thaller]

Manuel M T Chakravarty wrote:

> Wolfgang Thaller <wolfgang.thaller at gmx.net> wrote,
>
>> *) It violates requirement #4 "The specification shouldn't explicitly
>> require lightweight "green" 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.

It would be the first place where implementations of Concurrent Haskell 
are required to provide lightweight threads. Also, I expect Concurrent 
Haskell to be here to stay for some time, so tying the concurrency 
extension to the implementation technique that happens to be "standard" 
right now would IMHO still be a mistake.

>> *) 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.

Haskell so far has tried to be "safe" to use; this manual thread 
management is not safe, it smells like it's going to generate lots of 
bugs. This would be the first time that Haskell (+concurrency 
extension+libraries) is less safe than C (+OS libraries) in a 
particular area (threading). You just don't get that strange blocking 
behaviour in C.

It could even be argued that Proposal 3 is, in fact, not a minimal 
extension at all; If we have a multi-OS-thread Haskell implementation, 
we can implement Proposal 2 by
	threadbound = id
... but Proposal 3 can only be implemented by changing to a 
light-weight-thread based scheduler.

The explicit thread management of Proposal 3 requires run time systems 
to support situations where 3 Haskell threads are running in OS thread 
A, and two more Haskell threads are running in OS thread B. Who needs 
that, and what for?
It also requires runtime systems to actually use the native thread that 
a Haskell thread is bound to for it's execution (which happens to be 
the natural choice for GHC's implementation).

It should be possible to implement Proposal 2 for Hugs; my current 
impression is that Hugs' Concurrency implementation would have to be 
redone from scratch to support Proposal 3.

Cheers,

Wolfgang