-
Notifications
You must be signed in to change notification settings - Fork 44
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
fix: Use ring-buffer for WaitForFoo chans #1359
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1359 +/- ##
===========================================
- Coverage 70.65% 70.55% -0.11%
===========================================
Files 184 184
Lines 17818 17833 +15
===========================================
- Hits 12590 12582 -8
- Misses 4275 4294 +19
- Partials 953 957 +4
|
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. Once again, thanks for spotting this. It's a small but important fix.
pubSubEvent: make(chan net.EvtPubSub), | ||
pushLogEvent: make(chan net.EvtReceivedPushLog), | ||
peerEvent: make(chan event.EvtPeerConnectednessChanged), | ||
// WARNING: The current usage of these channels means that consumers of them |
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.
note: There is a chance that this 'feature' may enable tests to pass when they should not, if for example the WaitForFoo funcs are called later than they should.
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 is very true. But it would have been the case before as well but limited to the size of the event bus channel instead of the node channels above.
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.
Ah true! That's an interesting thought too, I wonder if that has been affecting things
Fixes a deadlock-like situation within P2P
Relevant issue(s)
Resolves #1357
Description
Introduces ring-buffer mechanics for WaitForFoo chans. This means that the go routines modified should never block, and that means that the libp2p
EventBus
should never fill to capacity, meaning it too should never block, which means the main P2P code should never block when doing P2P stuff (e.g. when callingEventBus.Emit
inserver.PushLog
).Massive thanks to Fred and John for showing me a very simple way of creating a ring-buffer in Go, I thought it would be way more complicated to do this.