-
Notifications
You must be signed in to change notification settings - Fork 112
Conversation
Calling `wg.Add` after `wg.Wait` has returned is invalid. This change swaps the wait group for a plain rwmutex. (caught with the race detector)
1972fcd
to
13f4ed3
Compare
059b761
to
0981b54
Compare
0981b54
to
e6a2a40
Compare
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.
See comment about switching to mutex + closed bool -- seems like the cancel channel is still more versatile, even w/o the waitgroup. I am new to this code though so grain of salt
notifications/notifications.go
Outdated
return | ||
default: | ||
} | ||
|
||
ps.wrapped.Pub(block, block.Cid().KeyString()) | ||
} | ||
|
||
// Not safe to call more than 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.
Pretty sure this comment no longer relevant. I mean not that you should, but looks like it'll just return early if you do
notifications/notifications.go
Outdated
@@ -107,9 +100,10 @@ func (ps *impl) Subscribe(ctx context.Context, keys ...cid.Cid) <-chan blocks.Bl | |||
if !ok { | |||
return | |||
} | |||
// We could end up blocking here if the client |
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 see that the waitgroup is the source of the race, and I get removing it, but I'm not 100% on why removing the cancel channel is needed, and it does seem like a nice way to insure these go routines get cleaned up, even if the subscribe client doesn't cancel context.
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 mostly just removed it because it wasn't absolutely necessary. We introduced it in the first place to avoid a lock, IIRC.
However, you're right. There's no reason not to have it.
Ensures that we don't leave goroutines behind, even if the client forgets to unsubscribe.
@hannahhoward fixed (and I've fixed another test race). |
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
fix multiple data races This commit was moved from ipfs/go-bitswap@722239f
wg.Add
afterwg.Wait
has returned is invalid. This change swaps the wait group for a plain rwmutex.(caught with the race detector)