-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
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. |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
utACK
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
CCoinJoinClientQueueManager
is dependent on blocks-only mode being disabled (which can be alternatively interpreted as enabling the relay of transactions). The same applies toCBlockPolicyEstimator
, whichCCoinJoinClientQueueManager
depends.Therefore,
CCoinJoinClientQueueManager
is only initialized if transaction relaying is enabled and so is its scheduled maintenance task. This can be found by looking atinit.cpp
here, here and here.For this reason,
CBlockPolicyEstimator
is not a member ofCJContext
and its usage is fulfilled by passing it as a reference when initializing the scheduling task.CJClientManager
has not usedCConnman
orCTxMemPool
asconst
as 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::AddPendingMasternode
which modifiesCConnman::vPendingMasternodes
, which is non-const behaviourCJClientManager::DoMaintenance > CCoinJoinClientManager::DoMaintenance > DoAutomaticDenominating > CCoinJoin::IsCollateralValid > AcceptToMemoryPool
which 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
Assert
incoinjoin/client.h
. This seems to be resolved by backporting bitcoin#24714. (Thanks @knst!)