Manuel M T Chakravarty wrote:
Wolfgang Thaller <wolfgang.thaller@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