Goroutine Scheduler (GMP)

Nothing blocks at the operating-system level. Go's runtime parks the goroutine, marking it waiting and detaching it from the thread, then runs another runnable goroutine on that same thread. The thread keeps doing useful work.

No. When a goroutine enters a system call that blocks, the Go runtime detaches its P (the scheduling context) from that OS thread, and another thread picks the P up and keeps running the remaining goroutines.

Nothing at the OS level blocks. The Go runtime parks that goroutine and records its wake time in a runtime timer heap, freeing the thread for other goroutines; when the deadline passes the goroutine becomes runnable again.

GOMAXPROCS sets the number of Ps, capping how many goroutines execute Go code at the same time. It does not cap how many goroutines you can create, and it is not a ceiling on the OS threads the runtime may create.

A safe point is an instruction where the runtime knows the goroutine's stack layout well enough to stop it, in practice a function prologue's stack check. Go 1.14 added asynchronous preemption, interrupting the thread with SIGURG when no safe point is reached.

It drains a batch from the global run queue, polls the network poller, then steals: up to four randomised passes over the other Ps, taking about half of a victim's local run queue. Only after all of that does its thread park.

By default the Go runtime prints a stack trace for every goroutine to standard error and then dies from the signal. It is a one-shot diagnostic: the process is killed, and deferred functions never run.

No. Since Go 1.14 the runtime interrupts a long-running goroutine on its own using a signal, so a tight loop no longer starves the rest of the program. runtime.Gosched() yields voluntarily and is rarely needed.

The new goroutine goes into the runnext slot of the P that ran the go statement, bumping any goroutine already there onto that P's 256-entry local run queue. When that queue is full, half of it spills to the global run queue.

runtime.NumGoroutine returns how many goroutines exist right now in any state: running, runnable, sleeping or blocked. It excludes goroutines that have already finished and the runtime's own system goroutines, and the value is a snapshot that can be stale the moment it returns.

A P owns the state needed to run goroutines: a queue of ready goroutines and per-P caches such as the memory-allocation cache. Requiring an M to hold a P keeps Go-code parallelism at exactly GOMAXPROCS while the thread count varies freely.

Go's runtime queues a wait record, called a sudog, for each blocked goroutine: it names the goroutine and the address the value goes to. A counterpart operation pops the first record from that channel's FIFO queue and readies its goroutine.

sysmon, the runtime's background monitor, checks each processor periodically and flags any goroutine that has held one for more than about 10 milliseconds, so the scheduler preempts it. A stop-the-world request preempts every running goroutine at once.

runnext is a single-goroutine fast slot on each P, holding the goroutine that P most recently made runnable. The P runs it ahead of its entire local run queue, and it inherits the remaining time slice rather than getting a fresh one.

Go opens network sockets in non-blocking mode and registers them with an event poller (epoll on Linux, kqueue on the BSDs, IOCP on Windows). A read with no data parks the goroutine, not the thread, and readiness makes the goroutine runnable again.

The runtime terminates that OS thread instead of reusing it. That is deliberate: a thread whose per-thread state was changed must not go on to run other goroutines, so exiting while still locked is the documented way to discard it.

Pending timers live in per-P min-heaps ordered by expiry, not one global list. Go's goroutine scheduler fires due ones while finding work, and a thread about to idle blocks in the netpoller until the earliest deadline.

schedtrace separates busy from stuck: idle Ps with empty run queues prove the extra goroutines are parked, not starved for CPU. Adding scheddetail=1 gives a line per goroutine with its wait reason, and a SIGQUIT dump gives each one's stack and how long it has been blocked.

Since Go 1.25 on Linux the default GOMAXPROCS is the lower of the usable CPU count and the container's cgroup CPU limit, so a rebuild on a newer toolchain gets far fewer Ps. Confirm by logging runtime.GOMAXPROCS(0) beside runtime.NumCPU().

Only another goroutine receiving from that channel, or closing it. A park carries no timeout and Go's scheduler never revisits waiting goroutines, so once the caller has gone, the send stays parked for the life of the process.

Work concentrates on the P that created it. A worker woken by a send on the jobs channel becomes runnable on the sender's P, so idle Ps get work only by stealing, which costs a search and takes the runnext slot last.

GOMAXPROCS bounds goroutines running Go code, not OS threads. Every goroutine parked in a blocking system call or a C call holds its own thread while the runtime spins up more to keep the scheduling contexts busy. Cap the blocking work, do not tune the scheduler.

The setns call changes only the calling OS thread, and the Go scheduler may resume the goroutine on a different thread after a syscall or a preemption. Pin with runtime.LockOSThread before entering, and let that goroutine exit rather than unlocking.

Two things. Unreferenced timers and tickers became ordinary garbage, collectable even if Stop was never called. And their channels became unbuffered, so Stop and Reset now guarantee no value prepared before the call is delivered after it.

Decide by how far the thread affinity reaches. If the whole affected operation happens inside one of your calls, pin internally and hide it. If the affinity outlives the call or caller code runs inside the pinned region, make pinning a documented obligation on the caller.

runtime.LockOSThread wires the calling goroutine to the OS thread it is running on: that goroutine runs only there, and no other goroutine runs on that thread. You need it for APIs that keep state per OS thread.

runqueue is the length of the scheduler's single global run queue, and the bracketed list gives each P's local run queue length, one entry per P. Both count goroutines that are runnable but not currently running; blocked goroutines appear in neither.

The sending goroutine copies the value straight into the parked receiver's destination variable, using the address in that receiver's wait record, then marks the receiver runnable. The channel's buffer is not used, even on a buffered channel.

Readiness notification does not work for regular files — the kernel will not usefully poll them, and non-blocking mode has no effect. So Go issues a real blocking read that occupies its OS thread, while sockets are registered with the poller and only park a goroutine.