Re:Comparison of the Go and Erlang concurrency models (2011)
by coldtea on Thursday December 04, 2014 @05:07AM
(#8698590)
>A pun? Maybe. But the point of calling them go-routines instead of co-routines is that they _are not coroutines_.
Well, the pun explanation makes more sense.
Because the mere fact that "they are not coroutines" doesn't explain their similar-to-coroutines name.
Or rather, it does explain why they are not called "coroutines" but does explain why they were named to sound like coroutines at all.
Re:Comparison of the Go and Erlang concurrency models (2011)
by ds300 on Thursday December 04, 2014 @05:01AM
(#8698574)
> With goroutines the cooperation is handled by the implementation/compiler -- i.e. Yield() calls are automatically inserted by the compiler -- rather than by the programmer manually by hand.
The compiler only inserts yeilds at some call sites. It's not a total solution like real preemptive scheduling, so you still need to be careful.
Re:Comparison of the Go and Erlang concurrency models (2011)
by Rapzid on Thursday December 04, 2014 @05:36AM
(#8698658)
That's old information; every function call causes the check now.
Re:Comparison of the Go and Erlang concurrency models (2011)
by gtani on Thursday December 04, 2014 @01:23PM
(#8700751)
Correct from 1.2, except inlined calls, see here http://stackoverflow.com/questions/21102078/golang-methods-t...
and http://dave.cheney.net/2014/06/07/five-things-that-make-go-f...
Re:Comparison of the Go and Erlang concurrency models (2011)
by slimsag on Thursday December 04, 2014 @01:14PM
(#8700682)
Newer Go versions (1.2 I think?) use preemptive scheduling so you don't have to do anything special: that's my point entirely.
Goroutines by specification have the potential to run all at the same time, in the exact way that OS-level threads do.
In older _implementatoins_ of Go, goroutines were not preemptively scheduled, and exactly as you say you had to be careful.
> Go calls its threads goroutines as a pun on coroutines, to indicate that they're lighter than real operating-system threads.
A pun? Maybe. But the point of calling them go-routines instead of co-routines is that they _are not coroutines_.
There isn't a requirement of cooperation on the programmer's part as there usually is with coroutines (at least as I experienced them in Python, having to place Yield() calls to let other coroutines run).
With goroutines the cooperation is handled by the implementation/compiler -- i.e. Yield() calls are automatically inserted by the compiler -- rather than by the programmer manually by hand.