A deep dive into Go's network poller (netpoller), explaining how the runtime provides a blocking-looking API while using non-blocking I/O under the hood. Covers the pollDesc data structure, the three-state parking protocol (pdNil/pdWait/goroutine pointer) that prevents lost wakeups, platform-specific kernel interfaces (epoll on Linux, kqueue on BSD/macOS, IOCP on Windows), deadline handling via runtime timers, stale event filtering with generation counters, and how the scheduler integrates netpoll to avoid dedicated poller threads. The result: a million concurrent connections on a handful of OS threads, with code that still reads like simple blocking calls.
Table of contents
The Problem: Blocking API, Non-Blocking RealityThe Journey of a Blocked ReadThe Kitchen Bell: Epoll, Kqueue, IOCPThe pollDesc : The Note at the TableParking: Falling Asleep Without Missing the BellWaking: Ringing the BellDeadlines: Giving Up Without Asking the KernelStale Notifications: Making Sure the Bell Belongs to YouWho Actually Calls netpoll ?Waking the Waiter: netpollBreakPutting It All TogetherSummarySort: