-
Notifications
You must be signed in to change notification settings - Fork 112
fix(network): add mutex to avoid data race #127
Conversation
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.
IMO, we need to rethink this a bit. The BitswapNetwork should have a Start method to register with the Host. We'd call that from Bitswap
after we finish setting everything up. That would make this lock unnecessary.
However, this works for now.
network/ipfs_impl.go
Outdated
@@ -172,18 +176,26 @@ func (bsnet *impl) Provide(ctx context.Context, k cid.Cid) error { | |||
func (bsnet *impl) handleNewStream(s inet.Stream) { | |||
defer s.Close() | |||
|
|||
bsnet.receiverLk.RLock() |
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.
Let's just stash a copy of the receiver here. That way we don't have to keep re-locking (it shouldn't change, right?).
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 makes sense
Maybe calling SetDelegate actually it was binds the host and starts receiving messages? It is called at the very end of the BS setup already |
SGTM. |
delay binding of network until a receiver is present. also add test of ipfs host network
916eb69
to
f67349e
Compare
@Stebalien re-implemented as suggested. I don't exactly know how to verify this is the right solution thought I did write a test and a cursory search shows most bitswap clients (cluster, ipfs, filecoin) initialize Bitswap shortly after initializing the network. |
This looks correct. |
And thanks for writing a test! You're setting a good example for the rest of us. |
fix(network): add mutex to avoid data race This commit was moved from ipfs/go-bitswap@e546588
Goals
Fix #125
Implementation
Adds a mutex to the network interface default implementation's receiver member. This appears to be the source of the data races in #125. While it's not totally clear if this covers all of the race conditions, it clearly something that should happen, since receiver is referenced repeatedly across multiple goroutines. Also adds a nil check to the notification methods.