Skip to content

Conversation

dergoegge
Copy link
Member

@dergoegge dergoegge commented Mar 14, 2023

We should define clear interfaces between CNode, CConnman and PeerManager. This PR makes a small step in that direction by ending the friendship of CNode, CConnman and ConnmanTestMsg. CNode's message processing queue is made private in the process and its mutex is turned into a non-recursive mutex.

@DrahtBot
Copy link
Contributor

DrahtBot commented Mar 14, 2023

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

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK vasild, theStack, brunoerg, jnewbery

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #25572 (refactor: Introduce EvictionManager and use it for the inbound eviction logic by dergoegge)
  • #25268 (refactor: Introduce EvictionManager by dergoegge)
  • #24545 (BIP324: Enable v2 P2P encrypted transport by dhruv)

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.

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.

Approach ACK 0e769e8

@dergoegge dergoegge force-pushed the 2023-03-cnode-friends branch from 0e769e8 to d02b99b Compare March 17, 2023 10:23
@dergoegge
Copy link
Member Author

@vasild Thanks for the review! Took all of your suggestions.

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 d02b99b

@dergoegge dergoegge force-pushed the 2023-03-cnode-friends branch from d02b99b to e29ecec Compare March 17, 2023 10:32
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 e29ecec

Copy link
Contributor

@brunoerg brunoerg left a comment

Choose a reason for hiding this comment

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

crACK e29ecec

nice cleanup!

@dergoegge dergoegge force-pushed the 2023-03-cnode-friends branch from e29ecec to 6514352 Compare March 19, 2023 13:42
@dergoegge
Copy link
Member Author

Rebased

Copy link
Contributor

@theStack theStack left a comment

Choose a reason for hiding this comment

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

Code-review ACK 6514352

@DrahtBot DrahtBot requested review from brunoerg and vasild March 21, 2023 01:03
@dergoegge dergoegge force-pushed the 2023-03-cnode-friends branch from 6514352 to 60c3f49 Compare March 21, 2023 14:38
Copy link
Contributor

@theStack theStack left a comment

Choose a reason for hiding this comment

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

re-ACK 60c3f49

Copy link
Contributor

@brunoerg brunoerg left a comment

Choose a reason for hiding this comment

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

re-ACK 60c3f49

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 60c3f49

Now that all access to the process queue members is handled by methods
of `CNode` we can make these members private.
-BEGIN VERIFY SCRIPT-
ren() { sed -i "s:\<$1\>:$2:g" $(git grep -l "\<$1\>" ./src ./test); }

ren cs_vProcessMsg    m_msg_process_queue_mutex
ren vProcessMsg       m_msg_process_queue
ren nProcessQueueSize m_msg_process_queue_size

-END VERIFY SCRIPT-
Both `CConnman` and `ConnmanTestMsg` no longer access private members of
`CNode`, we can therefore remove the friend relationship.
@dergoegge dergoegge force-pushed the 2023-03-cnode-friends branch from 60c3f49 to 3566aa7 Compare March 22, 2023 12:21
m_msg_process_queue_size -= msgs.front().m_raw_message_size;
fPauseRecv = m_msg_process_queue_size > recv_flood_size;

return std::make_pair(std::move(msgs.front()), !m_msg_process_queue.empty());
Copy link
Member Author

Choose a reason for hiding this comment

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

I was making a copy here of the CNetMessage, fixed now!

Easy to review with git range-diff 60c3f4918190900e5f79341abcc0878214656257...3566aa7d495bb783bbd135726238d9f2a9e9f80e.

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 3566aa7

@DrahtBot DrahtBot requested review from brunoerg and theStack March 23, 2023 13:25
Copy link
Contributor

@theStack theStack left a comment

Choose a reason for hiding this comment

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

re-ACK 3566aa7

Copy link
Contributor

@brunoerg brunoerg left a comment

Choose a reason for hiding this comment

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

re-ACK 3566aa7

@jnewbery
Copy link
Contributor

utACK 3566aa7

I didn't verify myself that the new code doesn't result in a copy of CNetMessage, but I trust that you've tested that. A follow up PR could potentially delete the default copy constructor for CNetMessage to ensure that we never copy.

All of my review comments are nits/style comments and shouldn't stop this from being merged.

node.nProcessQueueSize += nSizeAdded;
node.fPauseRecv = node.nProcessQueueSize > nReceiveFloodSize;
}
node.MarkReceivedMsgsForProcessing(nReceiveFloodSize);
Copy link
Contributor

Choose a reason for hiding this comment

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

Style nit: feel free to use a single line for single-line if blocks:

    if (complete) node.MarkReceivedMsgsForProcessing(nReceiveFloodSize);

Copy link
Contributor

Choose a reason for hiding this comment

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

That is a matter of personal taste (since both are allowed), but I just want to mention here why I, personally, avoid that:

  • It is not gdb friendly - you can't set a breakpoint on the if body (yes, one can set a breakpoint on the function call, but it becomes tedious if that function is called a lot from other places)
  • Creates bigger diff during changes in the future, comapre:
- if (A) B;
+ if (A) {
+     B;
+     C;
+ }

vs

 if (A) {
     B;
+    C;
 }

The latter is easier to read, especially if A, B and C are complex expressions.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that it's personal taste and the project style guide allows either.

It is not gdb friendly - you can't set a breakpoint on the if body (yes, one can set a breakpoint on the function call, but it becomes tedious if that function is called a lot from other places)

Are you familiar with conditional breakpoints? You can set the breakpoint to only stop the program if a boolean condition evaluates to true. Here, I think you could add the breakpoint:

break "net.cpp":68 if complete

and it would only stop if the if block is going to be called.

Copy link
Contributor

Choose a reason for hiding this comment

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

Alas that does not work if the condition includes function calls.

Copy link
Contributor

Choose a reason for hiding this comment

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

Alas that does not work if the condition includes function calls.

Why not? From the GDB docs:

Break conditions can have side effects, and may even call functions in your program.

@fanquake fanquake merged commit 2305643 into bitcoin:master Mar 23, 2023
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Mar 24, 2023
fanquake added a commit that referenced this pull request Mar 28, 2023
cd0c8ee [net] Pass nRecvFloodSize to CNode (dergoegge)
860402e [net] Remove trivial GetConnectionType() getter (dergoegge)
b5a85b3 [net] Delete CNetMessage copy constructor/assignment op (dergoegge)

Pull request description:

  Follow-up PR for #27257

  * Deletes the copy constructor/assignment operator of `CNetMessage`
  * Removes trivial getter for the connection type
  * Avoids passing `nRecvFloodSize` to CNode methods by passing it to `CNode` on creation

ACKs for top commit:
  jnewbery:
    utACK cd0c8ee
  theStack:
    ACK cd0c8ee

Tree-SHA512: 673a758668617f69fba77e61f0eaa1538da27a4849c82c98742436692baa2d7f001129af3e7a66b160e599d12109dac08137a146f10ff9b9ebdc5c2237311d41
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Mar 28, 2023
cd0c8ee [net] Pass nRecvFloodSize to CNode (dergoegge)
860402e [net] Remove trivial GetConnectionType() getter (dergoegge)
b5a85b3 [net] Delete CNetMessage copy constructor/assignment op (dergoegge)

Pull request description:

  Follow-up PR for bitcoin#27257

  * Deletes the copy constructor/assignment operator of `CNetMessage`
  * Removes trivial getter for the connection type
  * Avoids passing `nRecvFloodSize` to CNode methods by passing it to `CNode` on creation

ACKs for top commit:
  jnewbery:
    utACK cd0c8ee
  theStack:
    ACK cd0c8ee

Tree-SHA512: 673a758668617f69fba77e61f0eaa1538da27a4849c82c98742436692baa2d7f001129af3e7a66b160e599d12109dac08137a146f10ff9b9ebdc5c2237311d41
@bitcoin bitcoin locked and limited conversation to collaborators Mar 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants