net: when LookupIP is timed out, all duplicate lookups wait

[fraenkel]

It seems that if you have many goroutines that do lookups, they are tied to one routine that does the actual DNS resolve. If it succeeds, the answer is provided to everyone and all is happy.

When it times out, rather than releasing everyone, all the goroutines must also wait their time out too. It would make more sense to also release the other routines with the errTimeout immediately.

[minux]

what if the timeout is only temporary network flake? do you want to have one temporary failure affect all the duplicate lookups?

[fraenkel]

It won't matter. The code says to forget that host lookup, so the current ones are stranded. Only new calls after the "Forget" will cause a new Lookup.

[fraenkel]

@minux I see what you are saying....
What is odd though is that my Stacks are showing a bunch of routines waiting for an answer from a lookup but no routine is doing the lookup. While it could be a timing issue, I don't think I was that lucky.

I also noticed that the c.dups in the return is racy since it isn't guarded by a lock.

[fraenkel]

Here is the stack showing all the routines stuck in a lookup with nothing actually doing a lookup.
The dial timeout is 1s.

https://gist.github.com/fraenkel/5222c65dac27f5bb3ebc

[ianlancetaylor]

Which version of Go are you using? The file names suggest you are using a version before Go 1.4.

I expect that this was fixed in Go 1.4 by the fix for issue #8602.

[fraenkel]

This is Go 1.3. You are correct that it looks like with the Forget in there, this problem should go away.

But the c.dups on

go/src/net/singleflight.go

Line 62 in 77595e4

return c.val, c.err, c.dups > 0

seems racy. Are we relying on all the locking done doCall to make it have a current value?

[fraenkel]

Will close this out since its fixed in Go 1.4 and beyond.

[ianlancetaylor]

The reference to c.dups on line 62 is safe because it happens after doCall returns. After doCall returns the entry has been removed from the g.m map, which means that it will never again be modified. All modifications to the entry happen with the lock held, so the lock in doCall provides the necessary happens-before relation.