Skip to content

refactor: Group and re-order CAddrMan members by access type #22025

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.

Sign up for GitHub

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

Jump to bottom
Merged
laanwj merged 2 commits into from
May 27, 2021
Merged

refactor: Group and re-order CAddrMan members by access type #22025

laanwj merged 2 commits into from
May 27, 2021

Conversation

@hebasto
Copy link
Member

@hebasto hebasto commented May 23, 2021

This PR is split from #19238 as all of its commits are trivial to review.
The last commit is easy to review with git diff --color-moved=dimmed-zebra.

Addressed the following comments from #19238:

Can you consolidate all the private members and protected members to be next to each other? Multiple private and protected access specifiers make this harder to read than is necessary.

Yeah, class declaration is easier to read if there is just one instance of public:, protected: and private: (in that order).

@hebasto hebasto mentioned this pull request May 23, 2021
Merged
@DrahtBot
Copy link
Contributor

DrahtBot commented May 23, 2021 •
edited
Loading

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

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.

This was referenced May 23, 2021
Merged
Merged
Closed
Merged
vasild
vasild approved these changes May 24, 2021
View reviewed changes
Copy link
Contributor

@vasild vasild left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 6627b0b

vasild
vasild approved these changes May 24, 2021
View reviewed changes
Copy link
Contributor

@vasild vasild left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 1b177a4

@jnewbery
Copy link
Contributor

jnewbery commented May 24, 2021

ACK 1b177a4

laanwj
laanwj reviewed May 24, 2021
View reviewed changes
src/addrman.h Outdated
//! Update an entry's service bits.
void SetServices_(const CService &addr, ServiceFlags nServices) EXCLUSIVE_LOCKS_REQUIRED(cs);

friend class CAddrManCorrupted;
Copy link
Member

@laanwj laanwj May 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but I'm not 100% sure that having this class know about all descendents in the tests is better than using protected.

Copy link
Member Author

@hebasto hebasto May 24, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, one derived testing class has the friend specifier, others have access to protected members.
Is combining both approaches better?

Copy link
Member

@laanwj laanwj May 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say that if there is a choice, using protected is better than explicitly naming every descendant. Ideally you'd be able to add tests without having to mention them in the code to be tested. friend is like a last resort option for otherwise unrelated classes.

Copy link
Member Author

@hebasto hebasto May 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see.

Copy link
Member Author

@hebasto hebasto May 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! Updated.

@hebasto
move-only: Group and re-order CAddrMan members by access type
8caf60d 
Easy to verify with `git diff --color-moved=dimmed-zebra`.
@hebasto
Copy link
Member Author

hebasto commented May 24, 2021

Updated 1b177a4 -> 8caf60d (pr22025.02 -> pr22025.03, diff):

@hebasto hebasto changed the title refactor: Make CAddrMan protected members private ones refactor: Group and re-order CAddrMan members by access type May 24, 2021
@jnewbery
Copy link
Contributor

jnewbery commented May 24, 2021

ACK 8caf60d

@practicalswift
Copy link
Contributor

practicalswift commented May 24, 2021

Concept ACK

jarolrod
jarolrod reviewed May 26, 2021
View reviewed changes
Copy link
Contributor

@jarolrod jarolrod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 8caf60d

Patch looks correct

vasild
vasild approved these changes May 27, 2021
View reviewed changes
Copy link
Contributor

@vasild vasild left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 8caf60d

@laanwj
Copy link
Member

laanwj commented May 27, 2021

Code review ACK 8caf60d

@laanwj laanwj merged commit ea1e5c2 into bitcoin:master May 27, 2021
@hebasto hebasto deleted the 210523-cam branch May 27, 2021 13:55
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request May 27, 2021
@laanwj
Merge bitcoin#22025: refactor: Group and re-order CAddrMan members by…
f8c7c25 
… access…
maflcko pushed a commit that referenced this pull request Jun 14, 2021
Merge #19238: refactor: Make CAddrMan::cs non-recursive
3a2c84a 
ae98aec refactor: Make CAddrMan::cs non-recursive (Hennadii Stepanov)
f5d1c7f Add AssertLockHeld to CAddrMan private functions (Hennadii Stepanov)
5ef1d0b Add thread safety annotations to CAddrMan public functions (Hennadii Stepanov)
b138973 refactor: Avoid recursive locking in CAddrMan::Clear (Hennadii Stepanov)
f79a664 refactor: Apply consistent pattern for CAddrMan::Check usage (Hennadii Stepanov)
187b7d2 refactor: Avoid recursive locking in CAddrMan::Check (Hennadii Stepanov)
f77d9c7 refactor: Fix CAddrMan::Check style (Hennadii Stepanov)
0670397 Make CAddrMan::Check private (Hennadii Stepanov)
efc6fac refactor: Avoid recursive locking in CAddrMan::size (Hennadii Stepanov)
2da9554 test: Drop excessive locking in CAddrManTest::SimConnFail (Hennadii Stepanov)

Pull request description:

  This PR replaces `RecursiveMutex CAddrMan::cs` with `Mutex CAddrMan::cs`.

  All of the related code branches are covered by appropriate lock assertions to insure that the mutex locking policy has not been changed by accident.

  Related to #19303.

  Based on #22025, and first three commits belong to it.

ACKs for top commit:
  vasild:
    ACK ae98aec

Tree-SHA512: c3a2d3d955a75befd7e497a802b8c10730e393be9111ca263ad0464d32fae6c7edf9bd173ffb6bc9bb61c4b39073a74eba12979d47f26b0b7b4a861d100942df
gwillen pushed a commit to ElementsProject/elements that referenced this pull request Jun 1, 2022
@apoelstra
Merge ea1e5c2 into merged_master (Bitcoin PR bitcoin/bitcoin#22025)
af3617f
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@laanwj laanwj laanwj left review comments

+2 more reviewers

@jarolrod jarolrod jarolrod left review comments

@vasild vasild vasild approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

Refactoring

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

7 participants

@hebasto @DrahtBot @jnewbery @practicalswift @laanwj @vasild @jarolrod