refactor: subsume CoinJoin objects under CJContext, deglobalize coinJoin{ClientQueueManager,Server}#5337
Conversation
1c0f04d to
0d673b0
Compare
503777d to
26d1bb3
Compare
|
This pull request has conflicts, please rebase. |
|
This pull request has conflicts, please rebase. |
f8e495d to
8c86a5e
Compare
|
This pull request has conflicts, please rebase. |
…moving wallets Currently, CoinJoin sets itself up _after_ wallets have been loaded and destroys itself _before_ wallets have been removed. This approach worked earlier because they were pre-initialized, future commits will be converting them to a smart pointer, rendering their initialization order crucial.
|
Please take a look at this patch |
Co-authored-by: PastaPastaPasta <6443210+PastaPastaPasta@users.noreply.github.com>
|
This was initially why I used CI has shown that the patch caused problems (the exact same I found early on when working on this PR) and so I've reversed it. |
PastaPastaPasta
left a comment
There was a problem hiding this comment.
utACK for squash merge
|
btw, check this one: knst@be2494f |
It is a clever fix, though, this mildly obscures the circular dependency. Part of the deglobalization effort is to make the web of dependencies more self-documenting. I'm a bit uncertain about adding this, at least as part of this PR but would be fine if it was applied consistently for circular dependencies and then documented explicitly. Would be easier to document the origin of this practice. |
There was a problem hiding this comment.
IMO reference is [almost] always better than pointer because you never need to think can this object be nullptr? Should I check for nullptr?. There's still question who own it? but it is common between pointer and reference. if you want to show circular dependency clear as possible, may be need to add extra comment here?
btw, I am ok with knst@be2494f or whevener without it to approve PR because this PR looks as complete and whole anyway and my commit is just one more minor improvement that can be part of this or any next PR of coinjoin's refactorings.
Motivation
CoinJoin's subsystems are initialized by variables and managers that occupy the global context. The extent to which these subsystems entrench themselves into the codebase is difficult to assess and moving them out of the global context forces us to enumerate the subsystems in the codebase that rely on CoinJoin logic and enumerate the order in which components are initialized and destroyed.
Keeping this in mind, the scope of this pull request aims to:
Additional Information
The initialization of
CCoinJoinClientQueueManageris dependent on blocks-only mode being disabled (which can be alternatively interpreted as enabling the relay of transactions). The same applies toCBlockPolicyEstimator, whichCCoinJoinClientQueueManagerdepends.Therefore,
CCoinJoinClientQueueManageris only initialized if transaction relaying is enabled and so is its scheduled maintenance task. This can be found by looking atinit.cpphere, here and here.For this reason,
CBlockPolicyEstimatoris not a member ofCJContextand its usage is fulfilled by passing it as a reference when initializing the scheduling task.CJClientManagerhas not usedCConnmanorCTxMemPoolasconstas existing code that is outside the scope of this PR would cast away constness, which would be unacceptable. Furthermore, some logical paths are taken that will grind to a halt if they are stored asconst.Examples of such a call chains would be:
CJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoinClientSession::DoAutomaticDenominating > CCoinJoinClientSession::StartNewQueue > CConnman::AddPendingMasternodewhich modifiesCConnman::vPendingMasternodes, which is non-const behaviourCJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoin::IsCollateralValid > AcceptToMemoryPoolwhich adds a transaction to the memory pool, which is non-const behaviourThere were cppcheck linter failures that seemed to be caused by the usage of
Assertincoinjoin/client.h. This seems to be resolved by backporting bitcoin#24714. (Thanks @knst!)