|
|
|
|
|
by bkirwi
4112 days ago
|
|
It's worth noting that green threads are not 'enough' -- in any language with concurrency, you still need to be explicit about what work can run concurrently and what needs to be sequential. In Go, for example, the default is sequential operation; if you want to run a bunch of code concurrently, you need to do extra work to launch a bunch of new goroutines / wait for everyone to finish. In Haskell, which also (typically) has green threads, there's a popular `async` package that supplies a promise-like construct -- it's quite useful when you want to be explicit about concurrency and ordering. |
|
Let me just clarify one point: lightweight[1] threads are not an abstraction; threads are. Lightweight threads are simply threads whose implementation is such that blocking has no (or negligible) overhead. When you have threads, you're better off using blocking queues and blocking futures, which are the "pull" duals of the "push" mechanisms described in the article.
[1]: I don't like the term green threads because traditionally it's been used to describe threads that do not support parallelism.