libs/bits: inline defer and change order of mutexes#5187
Conversation
|
👋 Thanks for creating a PR! Before we can merge this PR, please make sure that all the following items have been
Thank you for your contribution to Tendermint! 🚀 |
a) it's not called outside b) the reason for exposing it in the first place is unclear c) Stop already exist if someone from outside wants to stop the client
Codecov Report
@@ Coverage Diff @@
## master #5187 +/- ##
==========================================
+ Coverage 60.83% 62.43% +1.59%
==========================================
Files 203 258 +55
Lines 20526 27129 +6603
==========================================
+ Hits 12488 16937 +4449
- Misses 6961 8718 +1757
- Partials 1077 1474 +397
|
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Good catch. The unlocks were probably both deferred earlier, and defers are executed in reverse order, so someone probably just blindly copied them into a function in the written order. Are the socket client changes supposed to be here? They seem unrelated to the bit array changes. |
Kinda. I've refactored socket client while investigating #3217 (comment) |
erikgrinaker
left a comment
There was a problem hiding this comment.
Ok, looks good in any case!
Closes #3217