Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain().
wallet: Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain() [wip] #11799
pull practicalswift wants to merge 1 commits into bitcoin:master from practicalswift:BlockUntilSyncedToCurrentChain-compile-time-warnings changing 1 files +1 −1-
practicalswift commented at 2:44 PM on November 30, 2017: contributor
-
wallet: Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain() 06f1bb1a8d
- practicalswift renamed this:
wallet: Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain()
wallet: Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain() [wip]
on Nov 30, 2017 -
practicalswift commented at 3:09 PM on November 30, 2017: contributor
Added a WIP-marker: Obviously the annotation should go into
wallet.hand notwallet.cpp. The problem is that the existence ofcs_mainis currently not known inwallet.h. What is the most appropriate way to solve that? I guess we don't wantextern CCriticalSection cs_main;inwallet.h? :-) - fanquake added the label Wallet on Nov 30, 2017
-
TheBlueMatt commented at 8:24 PM on December 4, 2017: member
Given that the LOCKS_EXCLUDED annotation only captures cases where the lock is taken in the same function as the call to BlockUntilSyncedToCurrentChain, I'm not sure the value of this. Indeed, obviously putting it in wallet.cpp is entirely useless, but it has only really marginal value. I'm open to discussion about whether its worth an extern CCriticalSection cs_main in wallet.h for this.
-
practicalswift commented at 8:29 PM on December 4, 2017: contributor
Yes,
LOCKS_EXCLUDEDis not transitive. Perhaps not worth it. Closing this PR. - practicalswift closed this on Dec 4, 2017
- practicalswift deleted the branch on Apr 10, 2021
- DrahtBot locked this on Aug 16, 2022
Contributors
Labels