Prevent leaks from time.After

[shoenig]

The use of time.After in a way that leaks goroutines is a common pitfall.

https://pkg.go.dev/time#After

The underlying Timer is not recovered by the garbage collector until the timer fires. If efficiency is a concern, use NewTimer instead and call Timer.Stop if the timer is no longer needed.

This is problematic in code structured something like,

for {
  select {
    case <- time.After(dur):
    case <- ch:
  }
}

which is a pattern we use in Nomad in quite a few places. If ch sends quickly, there can be a large number of allocated underlying channels from the call to After, which will hang around forever because there is nothing to read the returned value. A recent raft PR describes some of the performance impact of the acumulated allocations in more detail.

[github-actions]

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.