net: lookup: avoid creating a new goroutine if context is canceled and lookupIPAddr isn't actually resolving #59203
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Hello,
I've read
go/src/net/lookup.go
Lines 333 to 347 in 0aa14fc
I think It's preferable to avoid creating a new goroutine for waiting on a result whenever possible. If the context is canceled and
lookupIPAddr
isn't actually resolving, there's no need to wait for the result using a new goroutine.This is how we can achieve this:
ForgetNonFirstChan
tointernal/singleflight.Group
, which signature islookupIPAddr
, when context canceled, callForgetNonFirstChan
and if it returns true, we don't need to wait for the result, and callcancelFn
immediately without making a new goroutine.For example, suppose there is a situation where the first call of
LookupIPAddr
takes a long time, and then calls for name resolution for the same hostname are maden
times with a timeout of 5 seconds. Previously, even after 5 seconds had passed,n+1
goroutines were required, but after my modification, only one goroutine is required.I wrote a draft implementation on Gerrit
FYI:
I changed the data structure that holds the channels from a
slice
to amap
. This was done to improve the search(ForgetNonFirstChan needs searching) complexity from O(N) to O(1).The text was updated successfully, but these errors were encountered: