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

## What sysmon is The Go runtime starts one special thread during startup, conventionally called sysmon (system monitor). It is not a goroutine and it does not appear in a goroutine dump. It is an OS thread running a loop inside the runtime for as long as the process lives. ## Why it holds no P In Go's scheduler, a P is the permit to execute Go code; `GOMAXPROCS` sets how many exist, so at most that many goroutines run Go code at once. sysmon runs on a thread with **no P attached**, and that is deliberate. Consider what would happen otherwise. sysmon's job is to notice that a P has been sitting in a system call, that a goroutine has been running for a long time, that nobody has polled the network for a while, or that the heap has not been collected for minutes. Every one of those conditions is a situation in which the scheduler is saturated or stuck. A monitor that needed a scheduling permit would be queued behind precisely the work it is supposed to rescue: the deadlock-adjacent case where every P is occupied is the case where it must run. Running without a P makes sysmon independent of the scheduler it supervises. The cost is that it must work only with runtime internals that are safe to touch without a P. ## What it does each round - **Network polling.** If nothing has polled the network poller recently, sysmon does, so goroutines waiting on I/O become runnable even when every P is busy with CPU work. - **Retaking Ps.** A P whose goroutine has been in a system call for a while, or has been running without yielding, can be taken back so other goroutines get a turn. The detailed preemption machinery is a topic of its own; the point here is that the observation comes from outside the scheduler. - **Forcing collection.** If no garbage collection has run for about two minutes, sysmon triggers one, so a mostly idle program still returns memory and still runs finalisers and cleanups. ## Its duty cycle sysmon does not spin. It sleeps between rounds, starting at tens of microseconds and backing off towards about ten milliseconds when the program is idle, so an idle Go process is not burning a core on monitoring. When the program is busy it polls at the short end of that range. ## The consequence people actually meet Count the threads of a trivial Go program and there are several, more than `GOMAXPROCS` would suggest. `GOMAXPROCS` bounds Ps, not threads: the number of goroutines executing Go code simultaneously, not the number of OS threads the process holds. sysmon's thread is one of the extras and it is always there. Treating `GOMAXPROCS` as a thread limit is a common misreading and leads people to chase a thread count that was never going to match it. ## What sysmon is not It is not the garbage collector. The collector's mark work runs on ordinary worker goroutines that do consume Ps; sysmon merely notices when too long has passed and asks for a cycle. It is also not a goroutine you can see or profile, so goroutine dumps and goroutine counts do not include it. And it is not user-configurable: there is no knob to disable it, and the right mental model is that it is part of the runtime's floor cost, like the scheduler itself. ## Why an interviewer asks The question separates people who have read `GOMAXPROCS` as a CPU knob from people who understand the G/M/P split. If you can say that a P is a permit to run Go code, that sysmon deliberately holds none so it can act when all permits are taken, and that this is one reason thread count exceeds `GOMAXPROCS`, you have demonstrated the model rather than the vocabulary.