The Network Poller

In the previous article we saw how sysmon steps in every 10ms to call netpoll(0) on behalf of busy Ps, making sure network I/O doesn’t stall when the scheduler is too busy to poll on its own. We glossed over what that network poller actually is. Today we’re fixing that. Go’s networking story is one of its most quietly impressive tricks. You write code that looks blocking — conn.Read(buf), conn.Write(buf), listener.Accept() — and it reads exactly like the classic threaded servers from decades ago. But under the hood, no OS thread is actually blocked on those calls. Behind the scenes the runtime is driving epoll on Linux, kqueue on BSD/macOS, and I/O Completion Ports on Windows, parking and waking goroutines as readiness events arrive. The synchronous API you see is a comfortable illusion — and the machinery that maintains it is the network poller, or netpoller for short.