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