@MarcoFalke Good idea. Renamed from cs_feeEstimator to m_cs_fee_estimator. Please re-review :-)

@MarcoFalke Would you mind re-review this locking PR you looked at before? :-)

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #10443 (Add fee_est tool for debugging fee estimation code by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@Empact @MarcoFalke Updated. Would you mind re-reviewing? The current version is annotations only, so no change in locking. In other words: this PR changes only compile-time checking and no runtime behaviour. Should hence hopefully be trivial to review :-)

utACK 1a01e1c120809b19ddc9c9c6ee5d6686a90f55b3

Any chance of getting this reviewed? It is a compile time check only :-)

Adding EXCLUSIVE_LOCKS_REQUIRED(cs_feeEstimator) to processBlockTx caused a bunch of problems in #10443 due to cs_feeEstimator being a private member. In pr/fee.30, CTxMemPool::removeForBlock would call CBlockPolicyEstimator::processBlock, which would lock cs_feeEstimator, and then call a lambda passed from the caller to loop through transactions, calling CBlockPolicyEstimator::processTx which would call CBlockPolicyEstimator::processBlockTx. The new annotation to added processBlockTx caused the compiler to error on these calls.

The errors were spurious, since cs_feeEstimator was locked the entire time, but because cs_feeEstimator was a private member of CBlockPolicyEstimator, there was no way to annotate the lambda asserting that cs_feeEstimator was locked. Making the mutex public would have solved the problem, but instead in pr/fee.31 I opted to fix the problem by hiding the processBlockTx call in another callback to be less invasive and simplify some other things.

Just wanted to note this because some people were curious about it. I thought it was interesting because:

• There can sometimes be a tension between wanting to make mutexes private, and wanting to make assertions about them in code outside the class.

• There doesn't seem to be any way to annotate a std::function variable asserting that a mutex must always be locked before the function is called, and requiring the compiler to check this. It's possible to annotate a lambda assigned to a std::function variable, asserting that various mutexes are locked, but these assertions are completely unchecked and uncheckable without a way to annotate std::functions.