goroutine scheduling

[Nate Sutton]

I have a mental model of how Go schedules goroutines, I think, but I want to be sure it's correct. How I think it works is that goroutines on a single thread are scheduled by one goroutine yielding control to another, similar to cooperative multitasking (like Fibers in ruby). Many operations cause the goroutines to yield, like when there's IO of any sort, or when you use select or channels (internal IO, kinda). If there are multiple OS threads, then waiting goroutines are scheduled onto each of the threads as the goroutines running on the threads yield control.

Is this how goroutine scheduling works?

[Kyle Lemons]

On Wed, Mar 7, 2012 at 1:35 PM, Nate Sutton <nathan...@gmail.com> wrote:

I have a mental model of how Go schedules goroutines, I think, but I want to be sure it's correct. How I think it works is that goroutines on a single thread are scheduled by one goroutine yielding control to another, similar to cooperative multitasking (like Fibers in ruby). Many operations cause the goroutines to yield, like when there's IO of any sort, or when you use select or channels (internal IO, kinda). If there are multiple OS threads, then waiting goroutines are scheduled onto each of the threads as the goroutines running on the threads yield control.

Is this how goroutine scheduling works?

Definitely a workable model, yes.  A few additional things that might be of interest: I believe memory allocation can also yield control if the garbage collection threshold is reached, and channel I/O and/or select doesn't necessarily yield if the communication can proceed.

[minux]

Another one, normal syscall.Syscalls will yield, but syscall.RawSyscalls won't.

[fowlduck]

On Mar 7, 1:51 pm, Kyle Lemons <kev...@google.com> wrote:

Well, I understand that the various points at which yielding happens
may vary, and may vary quite a bit in the future as things change, but
I was just wondering about the high-level behavior.

Thanks. :)