3 ms·
Yeah. Goroutines not backed by real threads (afaik there's also gorountine -> os thread), those "green" threads from Ruby and fibers are just ugly hacks. Sorry
by mariusmg 12y ago
Yeah. Goroutines not backed by real threads (afaik there's also gorountine -> os thread), those "green" threads from Ruby and fibers are just ugly hacks.
Sorry but from my point of view, "real" concurrency is done at the OS level. The OS schedules threads to the CPU depending on their priority and "other" things. Having a single OS thread and runtime code that "yields" so another piece of code can run in the same thread, that's not concurrency...that's a toy.
Sorry for being so blunt.....but that's my opinion.
- cjslep 12y agoAt least initially, the gccgo compiler implemented goroutines as OS native threads and am wanting to say it still does.
- pritambaral 12y agoSwitching goroutines is much lighter than switching OS threads. When this "toy" and "hack" becomes as heavy or slow and thus no more useful than OS threads, then you can make a point. As I see it, you aren't making a point right now, just explaining what OS threads do and calling goroutines names. So let me point in the direction of an explanation of what goroutines do: http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_DeshpandeSponslerWeiss_GO.pdf http://www.cs.columbia.edu/~aho/cs6998/reports/12-12-11_Desh...