4 ms·
> Go supports green threads (goroutines) As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produce
by sinatra 11y ago
> Go supports green threads (goroutines)
As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.
- dragonwriter 11y ago> Go produces native code (no VM) Green threads can be managed by a runtime library or VM, so no VM doesn't mean no green threads. > the goroutines can be multiplexed (depending on implementation) to OS level threads. Being multiplexed onto OS level threads is normal for green threads. Goroutines are "hybrid" (M:N) rather than "user-level" (N:1) threads, but anything other than 1:1 native threading means that you need a runtime or VM managing it, and its a kind of green threads.
- sinatra 11y agoI see. So goroutines are just green threads with a nicer name? Thanks for correcting me. EDIT: Editing my comment because I can't reply to your reply. Yeah, I used "just" with the intention of saying that goroutines are well within the category/definition of green threads.
- dragonwriter 11y ago> So goroutines are just green threads with a nicer name? I don't know that I'd say "just": like Erlang processes, goroutines have some special features not shared by all other green threads, even with a similar M:N threading model. I'd say that Erlang processes and goroutines are each specific kinds of M:N green threads with unique features and distinct names. So, its useful to distinguish them within the broader category, they just shouldn't be distinguished from the category.