How timers rely on netpoll?

[GoStriver]

I noticed that the source code mentions in many places that timers depend on netpoll. However, I understand that timers are triggered via pp.timers.check() within findRunnable(). How exactly do timers rely on netpoll then? Am I missing something here?

func (ts *timers) addHeap(t *timer) {
assertWorldStoppedOrLockHeld(&ts.mu)
// Timers rely on the network poller, so make sure the poller
// has started.
if netpollInited.Load() == 0 {
netpollGenericInit()
}

if GOOS == "netbsd" && needSysmonWorkaround {
// netpoll is responsible for waiting for timer
// expiration, so we typically don't have to worry
// about starting an M to service timers. (Note that
// sleep for timeSleepUntil above simply ensures sysmon
// starts running again when that timer expiration may
// cause Go code to run again).
//
// However, netbsd has a kernel bug that sometimes
// misses netpollBreak wake-ups, which can lead to
// unbounded delays servicing timers. If we detect this
// overrun, then startm to get something to handle the
// timer.
//
// See issue 42515 and
// https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50094.
if next := timeSleepUntil(); next < now {
startm(nil, false, false)
}
}

[Ian Lance Taylor]

On Tue, Apr 1, 2025 at 10:24 AM GoStriver <wk100...@gmail.com> wrote:
>
>
> I noticed that the source code mentions in many places that timers depend on netpoll. However, I understand that timers are triggered via pp.timers.check() within findRunnable(). How exactly do timers rely on netpoll then? Am I missing something here?

A key aspect of timers in any language is how to ensure that an
otherwise idle program handles timers at the appropriate time. In the
Go runtime implementation that is done via netpoll. In an otherwise
idle program, a thread will be waiting for any network I/O, with a
timeout. That timeout is set such that the thread will wake up when it
is time for a timer to fire. The operation of waiting for network I/O
with a timeout is handled by netpoll.

Ian