/ go Public
net: lookup: avoid creating a new goroutine if context is canceled and lookupIPAddr isn't actually resolving #59203
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
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
lookupIPAddrisn't actually resolving, there's no need to wait for the result using a new goroutine.
This is how we can achieve this:
internal/singleflight.Group, which signature is
lookupIPAddr, when context canceled, call
ForgetNonFirstChanand if it returns true, we don't need to wait for the result, and call
cancelFnimmediately without making a new goroutine.
For example, suppose there is a situation where the first call of
LookupIPAddrtakes a long time, and then calls for name resolution for the same hostname are made
ntimes with a timeout of 5 seconds. Previously, even after 5 seconds had passed,
n+1goroutines were required, but after my modification, only one goroutine is required.
I wrote a draft implementation on Gerrit
I changed the data structure that holds the channels from a
map. 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: