-
Notifications
You must be signed in to change notification settings - Fork 37.7k
net processing: #26140 follow-ups #27379
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
Conversation
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.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee 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. |
CI failure is intermittent, see #27380 |
utACK 3fa4c54 |
Concept ACK. |
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 3fa4c54, I have reviewed the code and it looks OK, I agree it can be merged.
const TxRelay* GetTxRelay() const EXCLUSIVE_LOCKS_REQUIRED(!m_tx_relay_mutex) | ||
{ | ||
return WITH_LOCK(m_tx_relay_mutex, return m_tx_relay.get()); | ||
}; |
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.
Nice!
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 byg_msgproc_mutex
.