skip to content

Goroutine Scheduler (GMP)

How goroutines actually get onto CPUs: the G-M-P model, the run queues and work stealing that feed it, preemption of goroutines that will not yield, and what happens when one blocks on a syscall or the network. Backend interviews reach for this the moment you claim goroutines are cheap.

part ofGo (Golang)overview, primer and where to startread it →
on this pageshow

explore

questions

page 2 of 2

What is the Go runtime's sysmon thread, and why does it run without holding a P?

level: middleimportance: nice to knowfreq 24%

basics

~20 s

sysmon is a monitoring thread the Go runtime starts at program start and runs for the process lifetime. It holds no P, so GOMAXPROCS does not bound it and it can still act when every P is busy: polling the network, retaking Ps and forcing a periodic collection.

open as a page

Setting GODEBUG=asyncpreemptoff=1 makes a flaky failure disappear after a Go upgrade. What does that tell you?

level: seniorimportance: nice to knowfreq 22%

basics

~20 s

That the failure depends on the runtime interrupting goroutines with a signal at arbitrary instructions, since asyncpreemptoff=1 leaves only function-call preemption. Treat the setting as a bisect that narrows the bug, not as a fix to ship.

open as a page

What stops goroutines in Go's global run queue from starving behind the per-P local queues?

level: seniorimportance: nice to knowfreq 26%

basics

~20 s

On every 61st scheduling tick a P takes one goroutine from the global run queue before looking at its own, and a P that empties its local queue drains a global batch. Without the periodic check, local work would win forever.

open as a page

How does testing/synctest let a test of a one-hour backoff wait finish in milliseconds?

level: seniorimportance: nice to knowfreq 24%

basics

~20 s

It runs the test in a bubble with its own fake clock. That clock moves only when every goroutine in the bubble is durably blocked, then jumps to the next timer deadline, so no real waiting happens.

open as a page

Should a fleet pin GOMAXPROCS per service or rely on the container-aware default? How do you decide?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

Default to the runtime-derived value fleet-wide and treat pins as documented exceptions. The default is only trustworthy if every service builds on a toolchain that reads the container CPU limit and every workload actually has such a limit; otherwise pin.

open as a page

showing 31–35 of 35