-
Notifications
You must be signed in to change notification settings - Fork 724
Killing wallet and GUI cs_main locks #2209
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
Killing wallet and GUI cs_main locks #2209
Conversation
384252b to
2236d68
Compare
2236d68 to
4f76f13
Compare
for now, IsSpent() requires cs_main lock due its internal call to GetDepthInMainChain. This dependency will be completely removed moving forward, in bitcoin#2209
dfdf7df to
9384d4d
Compare
for now, IsSpent() requires cs_main lock due its internal call to GetDepthInMainChain. This dependency will be completely removed moving forward, in bitcoin#2209
23fc5c9 to
3c0a122
Compare
|
Rebased on top of master, plus after some testing on a big wallet (+76k transactions), expanded the work with some more improvements:
Plus some few other small bug fixes that found while was doing all of this. |
5f3f38d to
0df71e5
Compare
1484bc8 to
578a28e
Compare
|
Added few more commits, minimizing the amount of work required for the wallet to calculate the balance and to re-accept transactions at startup (both areas were walking through the entire wallet transactions set several times, looking for slightly different information, instead of doing it just once and grouping the results altogether). Affecting mostly to large wallets smoothness and decreasing their startup time considerably. |
The behavior of MacNotificationHandler::showNotification() has not been changed.
…wallet post initialization process
Coming from btc@fa795cf9c52b82cc3cccd21483360d6e03f767f0
future: add watch-only and CS balances distinction when/if they are needed (at the moment, they aren't). Inspired in btc@fa57411fcba00556ba25d45bca53cc04623da051 .
ClientModel::getBlockSource is locking cs_nodes every second and the result is currently not used.
…the screen is not visible.
…once. gui send screen: remove on-demand delegated balance calculation
So it doesn't invalidly re-use the cached one.
358a001 to
ca3edc5
Compare
|
Force-pushed it due a bug over the delegated balance update in the send screen (reported by fuzz).
|
Fuzzbawls
left a comment
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.
All good now, ACK ca3edc5
random-zebra
left a comment
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.
ACK ca3edc5 and merging...
…tChain + optimization 50dbec5 Add unit tests for signals generated by ProcessNewBlock() (furszy) f68251d Validation: rename one of the two instances using "bad-prevblk" to its correct description of "prevblk-not-found" (furszy) a51a755 Fix concurrency-related bugs in ActivateBestChain (Jesse Cohen) 198f435 Do not unlock cs_main in ABC unless we've actually made progress. (Matt Corallo) 8d15cf5 Optimize ActivateBestChain for long chains (Pieter Wuille) 8640be1 Fix fast-shutdown crash if genesis block was not loaded (Matt Corallo) ef24337 Hold cs_main while calling UpdatedBlockTip() and ui.NotifyBlockTip (Jesse Cohen) f9d2ab3 Update ValidationInterface() documentation to explicitly specify threading and memory model (Jesse Cohen) cb9bb25 Update documentation for SingleThreadedSchedulerClient() to specify the memory model (Jesse Cohen) 4ea2048 Add Unit Test for SingleThreadedSchedulerClient (Jesse Cohen) Pull request description: Made some back ports and adaptations to validate further the work introduced in #2203 and #2209. Now that the scheduler thread is processing most of the chain events, the callbacks execution order must be verified to dispatch the events serially, ensuring a consistent memory state in each event processing invocation. There are some concurrency issues solved, as well a an optimization for larger chains for the ABC workflow. Each commit details them well. List: bitcoin#7917 (only fb8fad1) bitcoin#12988 bitcoin#13023 bitcoin#13247 bitcoin#13835 This is built on top of #2284 (and the reason that made me notice that problem). So, 2284 comes first, then this one. ACKs for top commit: Fuzzbawls: ACK 50dbec5 random-zebra: ACK 50dbec5 and merging... Tree-SHA512: 573144cc96d2caa49ed2f0887dc8c53b5aca0efd54b6a25626063ccb780da426f56b3c6b7491648e7abefc1960c82b1354a4ff2c51425bfe99adaa4394562608
…fication fix f2734f0 [Tests] Fix policyestimator and validation_block tests (random-zebra) 3448bc8 wallet: Minimal fix to restore conflicted transaction notifications (Antoine Riard) ba9d84d feature_notifications.py mimic upstream is_wallet_compiled() function to make future back ports easier. (furszy) 37c9944 [mempool] Remove NotifyEntryAdded and NotifyEntryRemoved callbacks (John Newbery) 5cc619f [validation] Remove pool member from ConnectTrace (John Newbery) 1e453b7 [validation] Remove NotifyEntryRemoved callback from ConnectTrace (John Newbery) e774bfd [validation] Remove conflictedTxs from PerBlockConnectTrace (John Newbery) 389680a [validation interface] Remove vtxConflicted from BlockConnected (furszy) 19c9383 [wallet] Notify conflicted transactions in TransactionRemovedFromMempool (John Newbery) 139882d Fire TransactionRemovedFromMempool from mempool This commit fires TransactionRemovedFromMempool callbacks from the mempool and cleans up a bunch of code. (furszy) Pull request description: PR built on top of #2209, #2235 and #2240 (don't get scared by the amount of commits, most of them are coming from 2209. Will disappear as soon as that one gets merged). Based on the brief talk originated in #2209 (comment) . Solving the conflicted transactions external listeners notification. Adapting the following PRs: bitcoin#14384, bitcoin#17477 and bitcoin#18982. Without functional test support, for the time being, for the lack of RBF functionality. ACKs for top commit: Fuzzbawls: ACK f2734f0 random-zebra: re-utACK f2734f0 and merging... Tree-SHA512: 07d437e0d5e5d9798b16d982b6f58585d1f0dcd82251c5ac06f47e44233433831243d451ce43068e33c6002a64b76fa4d165167a2cbaeeedc28cde2019853565
…dling 57221af net_processing: Orphans map contemplating large shield transactions. (furszy) 9ec918f Deduplicate missing parents of orphan transactions (Suhas Daftuar) 488a0e3 Select orphan transaction uniformly for eviction (Pieter Wuille) d6e3ebe tests: Add missing locking annotations and locks (practicalswift) 3b7c9e5 Create new mutex for orphans, no cs_main in PLV::BlockConnected (Matt Corallo) 75cd6eb net_processing: Remove single zc transactions message ATMP call. (furszy) ba63837 net_processing: Do not process single zc transactions messages anymore. (furszy) f048869 net_processing: Add missing erase orphan transactions when a block is connected. (furszy) 71fd4b2 Remove mapOrphanTransactionsByPrev from DoS_tests (Pieter Wuille) 408a51a Align struct COrphan definition (Pieter Wuille) b5e650e Increase maximum orphan size to 100,000 bytes. (Gregory Maxwell) a065252 Treat orphans as implicit inv for parents, discard when parents rejected. (Gregory Maxwell) 59ff590 Adds an expiration time for orphan tx. (Gregory Maxwell) d7461b8 Track orphan by prev COutPoint rather than prev hash (Pieter Wuille) Pull request description: Upgraded the orphan transactions management process, getting us much closer to upstream. Skipped several intermediate PRs because our code is way too far ahead of them in some areas like the validation interface and block processing after #2209. Plus added a net_processing zc cleanup. Important changes: * The elimination of a leak in the orphan map, which was not connected to the block connection process, always growing to its maximum size. * Early detection and discard of zc txs received as single tx message. * Removal of the ATMP check of zc txs received as single tx message. * Removed the need of `cs_main` lock for accessing `mapOrphanTransactions` and `mapOrphanTransactionsByPrev`. ACKs for top commit: random-zebra: utACK 57221af Fuzzbawls: ACK 57221af Tree-SHA512: 816fd059fe0fb02d69f0c5d57ddfe4f569183a16e7a5fc6b643f4a7768674de6fd143232ec82b02c71c852b18b1d6e91a6f1ecc7b2ba576ba6db5d3f1498e657
8afb350 [GUI] Fix Cold Staking address list (Fuzzbawls) Pull request description: #2209 (specifically c2d66d0) introduced a visual bug with the display of cold staking addresses. Instead of showing the address as intended, the label was being duplicated. This restores the intended behavior. Without this patch:   With this patch:   ACKs for top commit: random-zebra: ACK 8afb350 furszy: ACK 8afb350 Tree-SHA512: c39701f4985926f8763faba060c741e8525b8a4674fa02004d1ec617133f6c65f3829adf5626e2d949b26be8a47a5961312c9fca261e5eaac3f6702dfddef0ee
This is the conclusion of a deep deep rabbit hole: #1726, #2150, #2082, #2118, #2150, #2179, #2191, #2192, #2195, #2201, #2203..
Effectively removing every
cs_mainlock from the wallet and GUI processing threads. Completely decoupling the wallet state and the visual interface update procedures from the main message and validation handler thread.Meaning that the messages & validation handler thread will be largely more active, accepting and verifying way more data in less time, not being affected by several other threads accessing to the main critical section. And, at the same time, the wallet and GUI worker threads will be able to perform and process their tasks concurrently, without waiting for the
cs_mainmutex acquisition.Improving the overall software performance, the GUI responsiveness and decreasing the synchronization time.
To make this possible, the wallet is maintaining in memory a view of the chain and updating it only via the validation interface signals. Using the view to perform all of the chain related calculations.