Addresses left over feedback from #26140.
mapRelay is only accessed from the message processing thread and does not need to be kept in sync with anything validation specific, it is therfore perfectly fine to have it guarded by g_msgproc_mutex.
Addresses left over feedback from #26140.
mapRelay is only accessed from the message processing thread and does not need to be kept in sync with anything validation specific, it is therfore perfectly fine to have it guarded by g_msgproc_mutex.
Taking cs_main is no longer necessary since we moved
`m_recently_announced_invs` to `Peer` and `mapRelay` is actually only
accessed from the message processing thread.
915 | @@ -920,9 +916,9 @@ class PeerManagerImpl final : public PeerManager 916 | 917 | /** Relay map (txid or wtxid -> CTransactionRef) */ 918 | typedef std::map<uint256, CTransactionRef> MapRelay; 919 | - MapRelay mapRelay GUARDED_BY(cs_main); 920 | + MapRelay mapRelay GUARDED_BY(NetEventsInterface::g_msgproc_mutex);
Mention this in the PR description?
Done
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
utACK 3fa4c54ac54b2d738e0c43b57b5c232ee02fe3b3
Concept ACK.
316 | @@ -317,10 +317,6 @@ struct Peer { 317 | { 318 | return WITH_LOCK(m_tx_relay_mutex, return m_tx_relay.get()); 319 | }; 320 | - const TxRelay* GetTxRelay() const EXCLUSIVE_LOCKS_REQUIRED(!m_tx_relay_mutex) 321 | - { 322 | - return WITH_LOCK(m_tx_relay_mutex, return m_tx_relay.get()); 323 | - };
Nice!
ACK 3fa4c54ac54b2d738e0c43b57b5c232ee02fe3b3, I have reviewed the code and it looks OK, I agree it can be merged.