-
Notifications
You must be signed in to change notification settings - Fork 112
Conversation
Jenkins seems to be out of space, hence broken builds |
} | ||
} | ||
} | ||
|
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.
I realize this somewhat reimplements sync.Map, but I find sync.Map relatively useless due to the lack of typing on the values (which can't be avoided given Go's lack of Generics at the moment)
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.
The current locking pattern looks a bit suspect. We're taking a lock to pull an item out of the map but then we're mutating that item without the lock.
|
||
// new peer, we will want to give them our full wantlist | ||
// AddWantlist adds a complete session tracked want list to a message queue | ||
func (mq *MessageQueue) AddWantlist(initialEntries []*wantlist.Entry) { |
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.
TODO (maybe later): It would be kind of nice to deduplicate this with AddMessage
. As far as I can tell, they do approximately the same thing; they just take different inputs.
peermanager/peermanager.go
Outdated
message.handle(pm) | ||
case <-pm.ctx.Done(): | ||
return | ||
if 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.
Are Disconnect/Connect really safe? pm.get
takes a lock internally but then we modify stuff without a lock. That seems a bit odd.
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.
I mean you're potentially mutating the object, but not its reference. The object itself is responsible for keeping internal mutations threadsafe. THOUGH I acknowledge that actually currently the refcount stuff is not thread safe. I think that should be handled inside the object though.
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.
I'm not sure about remove I need to double check.
peermanager/peermanager.go
Outdated
log.Infof("tried sending wantlist change to non-partner peer: %s", t) | ||
continue | ||
p = pm.createPeerQueue(t) | ||
pm.set(t, p) |
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.
Can nothing call this concurrently? If so, I assume we'd need some kind of atomic GetOrCreate kind of thing.
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.
mmm. good point. I get it.
@Stebalien I think I fixed the locking pattern, but feel free to double check. Also builds seem stalled for linux. |
When rebased on #76 and tested against the race detector, I'm getting the following error. It looks like
|
Diff to fix the current race:
Other than that, the race detector isn't agreeing with my spidy senses. |
fix race conditions while setting up wantlists by creating peer queues on demand BREAKING CHANGE: PeerManager SendMessage signature changed fix #51
Limit retrying sending of a message even when a successful reconnect occurs
If wantlist changes are present, send them immediately on startup, rather than as a seperate message
Breakup Startup function so that wantlists are not sent with each call to SendMessage
Constrain use of mutex to actual operations on the peerQueues map via utility functions
repace get/set with getOrCreate to keep operations atomic
Keep all of disconnection in a mutex
fix remaining issues for race detector in peer manager
8dd1682
to
434e0f4
Compare
Move refcnt tracking from the messagequeue to the peermanager, where it's relevant
055f143
to
d4191c4
Compare
…ndling fix(wantlist): remove races on setup This commit was moved from ipfs/go-bitswap@472a8ab
Goals
fix race conditions while setting up wantlists
Implementation
This change essentially solves bugs in initial wantlist handling using the strategy outlined by @Stebalien in #51.
This means two differences:
Other notable changes:
For Discussion
fix #51 fix #48