You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The use of
time.After
in a way that leaks goroutines is a common pitfall.https://pkg.go.dev/time#After
This is problematic in code structured something like,
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 toAfter
, 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.The text was updated successfully, but these errors were encountered: