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.

@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.

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

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.

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

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

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.