-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
swarm: remove unnecessary reqno for pending request tracking #2416
Conversation
if !ok { | ||
// some other dial for this request succeeded before this one | ||
continue | ||
for pr := range w.pendingRequests { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This loop will now be executed in random order. Is that ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
continue | ||
} | ||
|
||
for pr := range w.pendingRequests { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. Assuming we have two go routines waiting.
- We don't actually guarantee ordered delivery. This just publishes to a channel. This channel is being read here. So the waiting go routines may be run in a different order.
- This doesn't block. The channel has 1 capacity, so both the waiters are notified immediately.
I don't know of any case where this might be an issue especially considering 1.
Also here we do provide an out of order delivery. In this case the first requester will be informed of the connection after the second requester(which added a valid address) was informed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, this looks like a nice simplification. I don't think it resolves #2380 though.
First merge this to backoff cleanup and then we can merge both to master.
Opening small PRs for individual items since this piece is complicated