| >> *) 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. This is a good point, and one we hadn't really understood before. I thought that P3 required green threads even less than P1 and P2, but it's quite the reverse, which is a bit counter intuitive. Thus motivated, I've sketched Proposal 4, which is a sort of combinatory of P2 and P3. Much simpler than P2, but addressing the concerns Wolfgang raises. The main difference relative to P3 is that a Haskell thread is either unbound or bound to a native thread N Like P2, it has the property that at most one Haskell thread can be bound to a native thread N. Also like P1 and P2, the unbound Haskell threads can be executed one-per-native-thread, or by a pool of worker native threads, as you please. Unlike P2, there is no notion of an "associated" native thread, or of "temporary binding" of a Haskell thread to a native thread. Details in CVS, and in a Postscript file that I'll send separately (I'm having trouble with my externally-visible web site). Wolfgang, does this help? Simon | | 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 |