-
Notifications
You must be signed in to change notification settings - Fork 905
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
Made PendingAddOp thread safe #3784
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3784 +/- ##
============================================
+ Coverage 68.08% 68.18% +0.10%
- Complexity 6712 6723 +11
============================================
Files 473 473
Lines 40952 40930 -22
Branches 5236 5235 -1
============================================
+ Hits 27882 27909 +27
+ Misses 10808 10762 -46
+ Partials 2262 2259 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
Good job!
Motivation
PendingAddOp
is not thread-safe and the BK client instead follows a pattern of "jumping" to a particular thread for both the requests and the callback path.This is in practice much more expensive than acquiring a mutex since in most cases the caller will have already serialized the calls to
ledger.append()
.With this change, we can avoid 2 context switches and the very big contention on the executor queues used between the threads.