When a goroutine calls time.Sleep, what does the Go runtime block, and what wakes it?

## The question behind the question Engineers arriving from a thread-per-request language read `time.Sleep(30 * time.Second)` and wince: thirty seconds of a thread doing nothing. In Go that instinct is wrong, and understanding why is the entry point into how the runtime keeps time. ## What actually happens on a Sleep Go multiplexes many goroutines (Gs) onto a smaller number of OS threads (Ms), each of which needs a scheduling context (a P) to run Go code. `time.Sleep` calls into the runtime and does two things: 1. **It parks the calling goroutine.** The goroutine's state changes from running to waiting, and it is not on any run queue, so the scheduler will not pick it up. Its stack and its saved registers stay on the heap, waiting to be resumed. 2. **It records a timer.** The runtime creates a small timer object holding the wake-up instant (a monotonic-clock value, not a wall-clock time) and pushes it onto a min-heap of pending timers ordered by expiry. That heap belongs to a P, not to the whole process. The OS thread then returns to the scheduler and picks up other runnable goroutines. Nothing in the kernel knows a Go-level sleep is in progress. There is no thread parked on it, no `nanosleep` per sleeping goroutine, and no per-timer kernel object. ## What wakes it Go's goroutine scheduler looks at the pending-timer heap as part of its normal work-finding pass. Any timer whose deadline has passed is fired: for a `Sleep`, firing simply marks the sleeping goroutine runnable again and puts it on a run queue. The interesting case is when there is no work at all. Rather than spinning, the thread blocks in the runtime's network poller — `epoll_wait` on Linux, `kqueue` on BSD and macOS. The runtime passes the **earliest pending timer deadline as that wait's timeout**, so the thread wakes either because I/O became ready or because the next timer is due, whichever comes first. One blocking OS call therefore covers arbitrarily many Go timers. That is the whole trick: the runtime folds N Go deadlines into one OS deadline. If a P goes idle while still holding pending timers, the runtime does not let them stall — another P takes responsibility for them, and the runtime's monitoring thread acts as a backstop that can wake a thread when a timer comes due. ## The guarantee you actually get `time.Sleep(d)` pauses for **at least** `d`. It can never return early: it is measured against the monotonic clock, so a system clock adjustment (NTP stepping the wall clock backwards, for instance) does not shorten or lengthen it. It can easily return late, because firing the timer only makes the goroutine *runnable*; the goroutine then waits its turn behind whatever else is queued. On a service that is saturating every P, a 10 ms sleep returning 40 ms later is ordinary, not a bug. Treat sleeps and timers as lower bounds, never as a schedule. ```go start := time.Now() time.Sleep(10 * time.Millisecond) // time.Since(start) >= 10ms, always; how much more depends on load ``` ## The cost model A sleeping goroutine costs its (growable) stack plus one entry in a timer heap. An OS thread blocked in a kernel sleep costs a full thread: a large stack reservation and kernel scheduling state. This is why designs that would be reckless with threads — a hundred thousand connections each with a keep-alive delay, or a backoff layer that holds a goroutine per in-flight retry — are unremarkable in Go. The corollary matters for capacity planning: goroutines parked on timers are almost free in CPU terms, but the moment a large batch of them comes due simultaneously, they all become runnable at once and compete for the same Ps. A thundering herd of expiring backoff timers is a real production shape; jitter on the durations exists to spread that out. ## What to say in an interview "The goroutine is parked and the thread is handed back to the scheduler. The wake-up time goes on a runtime timer heap owned by a P, and the runtime uses the earliest deadline as the timeout of the one blocking wait it already makes for network readiness. So sleeping costs a heap entry, not a thread — and `Sleep` means at least that long, never exactly."