-
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
relay: fix deadlock when closing #2171
Conversation
r.host.RemoveStreamHandler(proto.ProtoIDv2Hop) | ||
r.host.Network().StopNotify(r.notifiee) | ||
r.scope.Done() | ||
r.cancel() | ||
|
||
r.mx.Lock() |
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.
Would it make sense to move the untagging a few lines up? That way you'd only need to lock the mutex once.
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.
That line actually has a race condition :(
if both r.gc and r.Close(waiting on lock before untag peer) happen at the same time we'd untag the peer twice with the conn manager since in close we don't delete the entry from the map.
I updated it to also cleanup the background goroutine like it happens in other services. If you want I'll make the exact change you asked.
r.host.RemoveStreamHandler(proto.ProtoIDv2Hop) | ||
r.host.Network().StopNotify(r.notifiee) | ||
r.scope.Done() | ||
r.cancel() | ||
for p := range r.rsvp { | ||
r.host.ConnManager().UntagPeer(p, "relay-reservation") | ||
} |
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.
Where does the untagging happen now?
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.
fixes: #2167