3 ms·
In Go, the coroutines are in the same thread. There is a single thread here too(just like node.js). Coroutines are just multiplexed to the one main thread. Mult
by realrocker 14y ago
In Go, the coroutines are in the same thread. There is a single thread here too(just like node.js). Coroutines are just multiplexed to the one main thread. Multi-Core Processing is handled by coroutine internals too i.e. there may or may not be more than one threads and even if there are more than one threads, they too will be multiplexed with the one main thread.
- 4ad 14y agoGoroutines running Go code are multiplexed onto a variable number of system threads (GOMAXPROCS, in the gc implementation), Goroutines running C code, for example via cgo, or when they call a blocking system call, have their own thread.
- realrocker 14y agoYes I get that. I just wanted to point out that a single threaded model is not necessarily a bad thing. It happens in GO too by default.
- strmpnk 14y agoI think that's more of a matter of scheduler still being immature. Erlang only added an SMP scheduler in R11 due to the complexities of managing internal state without sacrificing it's soft-realtime abilities. It was also only really reliable after R12. I'm sure Go will mature here and the defaults will evolve along with that. Whether that will take years or not is up for debate but at least it's a possibility and doesn't cost the programmer anything other than a recompile if they start with careful use of goroutines today.
- Jabbles 14y agoI believe the number of threads can be higher than GOMAXPROCS, but only GOMAXPROCS can be running at once. https://groups.google.com/d/topic/golang-nuts/bP6_KD51ed4/discussion https://groups.google.com/d/topic/golang-nuts/bP6_KD51ed4/di...
- aaronblohowiak 14y ago>In Go, the coroutines are in the same thread. .. until you set runtime.GOMAXPROCS(runtime.NumCPU())