👍 ryanofsky approved a pull request: "refactor: Replace g_genesis_wait_cv with m_tip_block_cv"
(https://github.com/bitcoin/bitcoin/pull/30967#pullrequestreview-2328408540)
Code review ACK fa61644768c3f6932860d1c5e2c6c0a38d5257e5.
Overall very nice changes, but I think the first commit fa5ac85d19a387c2e12fc0833368e1240a3dcf51 has a drawback because it adds a `NodeContext` argument to `RPCStop` when ideally RPC code should be agnostic to node initialization and not depend on node types. Would suggest following change to clean it up, which could be squashed into the first commit:
- ef271bc75e7bea8c82ce8667fb22e9b25dca5712 refactor: Split up NodeContext shutdown
...
(https://github.com/bitcoin/bitcoin/pull/30967#pullrequestreview-2328408540)
Code review ACK fa61644768c3f6932860d1c5e2c6c0a38d5257e5.
Overall very nice changes, but I think the first commit fa5ac85d19a387c2e12fc0833368e1240a3dcf51 has a drawback because it adds a `NodeContext` argument to `RPCStop` when ideally RPC code should be agnostic to node initialization and not depend on node types. Would suggest following change to clean it up, which could be squashed into the first commit:
- ef271bc75e7bea8c82ce8667fb22e9b25dca5712 refactor: Split up NodeContext shutdown
...
💬 ryanofsky commented on pull request "refactor: Replace g_genesis_wait_cv with m_tip_block_cv":
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775316336)
In commit "refactor: Replace g_genesis_wait_cv with m_tip_block_cv" (faaf888eb275cecc2d2803c5756afac633e0e2a4)
This code is waiting for `m_tip_block` to be non-null, but then code below will be assuming that `chainman.ActiveTip()` will be non-null. These are similar conditions but not exactly the same, so I think it would be good to add an assert below the if statement like `assert(WITH_LOCK(chainman.GetMutex(), return chainman.ActiveChain().Tip() != nullptr));` to make sure this code is func
...
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775316336)
In commit "refactor: Replace g_genesis_wait_cv with m_tip_block_cv" (faaf888eb275cecc2d2803c5756afac633e0e2a4)
This code is waiting for `m_tip_block` to be non-null, but then code below will be assuming that `chainman.ActiveTip()` will be non-null. These are similar conditions but not exactly the same, so I think it would be good to add an assert below the if statement like `assert(WITH_LOCK(chainman.GetMutex(), return chainman.ActiveChain().Tip() != nullptr));` to make sure this code is func
...
💬 ryanofsky commented on pull request "refactor: Replace g_genesis_wait_cv with m_tip_block_cv":
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775328397)
re: https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775211951
I'm not sure about the steady clock thing, but I think the reason this code is written to use a while loop is because it wants to wake up every 1000ms to check m_interrupt in case `m_interrupt` was signaled without `m_tip_block_cv` being signalled. Since I posted another change above to ensure that signalling `m_interrupt` will reliably signal `m_tip_block_cv`, I think this code could be changed to use a simple wait pred
...
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775328397)
re: https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775211951
I'm not sure about the steady clock thing, but I think the reason this code is written to use a while loop is because it wants to wake up every 1000ms to check m_interrupt in case `m_interrupt` was signaled without `m_tip_block_cv` being signalled. Since I posted another change above to ensure that signalling `m_interrupt` will reliably signal `m_tip_block_cv`, I think this code could be changed to use a simple wait pred
...
👍 TheCharlatan approved a pull request: "refactor: Replace g_genesis_wait_cv with m_tip_block_cv"
(https://github.com/bitcoin/bitcoin/pull/30967#pullrequestreview-2328454931)
ACK fa61644768c3f6932860d1c5e2c6c0a38d5257e5
(https://github.com/bitcoin/bitcoin/pull/30967#pullrequestreview-2328454931)
ACK fa61644768c3f6932860d1c5e2c6c0a38d5257e5
💬 TheCharlatan commented on pull request "refactor: Replace g_genesis_wait_cv with m_tip_block_cv":
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775344259)
Nit: Could forward-declare `NodeContext` here instead.
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775344259)
Nit: Could forward-declare `NodeContext` here instead.
💬 maflcko commented on issue "win64-cross CI timeout after 2h":
(https://github.com/bitcoin/bitcoin/issues/30969#issuecomment-2374284122)
This is odd, because normally it should pass in less than 15 minutes:https://cirrus-ci.com/task/4920689327603712
Looks like `allocator_tests` never finished.
(https://github.com/bitcoin/bitcoin/issues/30969#issuecomment-2374284122)
This is odd, because normally it should pass in less than 15 minutes:https://cirrus-ci.com/task/4920689327603712
Looks like `allocator_tests` never finished.
💬 maflcko commented on pull request "refactor: Replace g_genesis_wait_cv with m_tip_block_cv":
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775409498)
> These are similar conditions but not exactly the same
The `m_tip_block` condition implies the `Tip()` condition, because `SetTip()` happens before `blockTip()`.
An assert (`Assert`) is already present in the next commit, which was asked to be split up: https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775007062
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775409498)
> These are similar conditions but not exactly the same
The `m_tip_block` condition implies the `Tip()` condition, because `SetTip()` happens before `blockTip()`.
An assert (`Assert`) is already present in the next commit, which was asked to be split up: https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775007062
📝 maflcko converted_to_draft a pull request: "refactor: Replace g_genesis_wait_cv with m_tip_block_cv"
(https://github.com/bitcoin/bitcoin/pull/30967)
`g_genesis_wait_cv` is similar to `m_tip_block_cv` but shuffling everything through a redundant `boost::signals2`.
So remove it, along with some other dead code, as well as minor fixups.
(https://github.com/bitcoin/bitcoin/pull/30967)
`g_genesis_wait_cv` is similar to `m_tip_block_cv` but shuffling everything through a redundant `boost::signals2`.
So remove it, along with some other dead code, as well as minor fixups.
👋 maflcko's pull request is ready for review: "refactor: Replace g_genesis_wait_cv with m_tip_block_cv"
(https://github.com/bitcoin/bitcoin/pull/30967)
(https://github.com/bitcoin/bitcoin/pull/30967)
👍 ryanofsky approved a pull request: "init: Remove retry for loop"
(https://github.com/bitcoin/bitcoin/pull/30968#pullrequestreview-2328680000)
Code review ACK 705105de4f84f2ce3bb1d754c88c32349e01bb3b
Nice cleanup. Previous for loop was very confusing and new code is straightforward.
Not important, but I think it would be a little better if `InitAndLoadChainstate` simply returned `ChainstateLoadStatus` instead of `std::tuple</*may_retry*/ bool, /*error*/ bilingual_str>`. This way retry logic would be implemented in one function, not split across two functions. And it would avoid introducing a new way to represent success/interrupt
...
(https://github.com/bitcoin/bitcoin/pull/30968#pullrequestreview-2328680000)
Code review ACK 705105de4f84f2ce3bb1d754c88c32349e01bb3b
Nice cleanup. Previous for loop was very confusing and new code is straightforward.
Not important, but I think it would be a little better if `InitAndLoadChainstate` simply returned `ChainstateLoadStatus` instead of `std::tuple</*may_retry*/ bool, /*error*/ bilingual_str>`. This way retry logic would be implemented in one function, not split across two functions. And it would avoid introducing a new way to represent success/interrupt
...
💬 maflcko commented on pull request "refactor: Replace g_genesis_wait_cv with m_tip_block_cv":
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775481467)
Thanks, but closing as no longer relevant. I'll follow-up with iwyu at some point, which should fix all of this either way.
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775481467)
Thanks, but closing as no longer relevant. I'll follow-up with iwyu at some point, which should fix all of this either way.
💬 itornaza commented on pull request "multiprocess: Add IPC wrapper for Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30510#issuecomment-2374471920)
> My `clang-tidy` also wants to indent the `requires` expressions, but I don't think that is necessarily more readable.
Checking with the C++ Core Guidelines and Stroustrup's books, while they do not mention anything about indenting require statements, they do indent it all through the guide like in this [minimal example](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rt-raise)
(https://github.com/bitcoin/bitcoin/pull/30510#issuecomment-2374471920)
> My `clang-tidy` also wants to indent the `requires` expressions, but I don't think that is necessarily more readable.
Checking with the C++ Core Guidelines and Stroustrup's books, while they do not mention anything about indenting require statements, they do indent it all through the guide like in this [minimal example](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rt-raise)
💬 maflcko commented on pull request "refactor: Replace g_genesis_wait_cv with m_tip_block_cv":
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775489809)
> I'm not sure about the steady clock thing
I was referring to https://en.cppreference.com/w/cpp/thread/condition_variable/wait_until#Notes, but it can probably be dropped. I just wanted to mention that it may not be a refactor in a strict sense.
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775489809)
> I'm not sure about the steady clock thing
I was referring to https://en.cppreference.com/w/cpp/thread/condition_variable/wait_until#Notes, but it can probably be dropped. I just wanted to mention that it may not be a refactor in a strict sense.
👍 itornaza approved a pull request: "multiprocess: Add IPC wrapper for Mining interface"
(https://github.com/bitcoin/bitcoin/pull/30510#pullrequestreview-2328717165)
ACK 1a332817665f77f55090fa166930fec0e5500727
Very clever rework to maximize code reuse while using already existing concepts. The code is now far easier to read. Built locally and all unit, and functional tests pass including the extended.
(https://github.com/bitcoin/bitcoin/pull/30510#pullrequestreview-2328717165)
ACK 1a332817665f77f55090fa166930fec0e5500727
Very clever rework to maximize code reuse while using already existing concepts. The code is now far easier to read. Built locally and all unit, and functional tests pass including the extended.
👍 ryanofsky approved a pull request: "refactor: Replace g_genesis_wait_cv with m_tip_block_cv"
(https://github.com/bitcoin/bitcoin/pull/30967#pullrequestreview-2328742682)
Code review ACK fa7c2c9f18f5468baf81c04177b75e2b684a327a
(https://github.com/bitcoin/bitcoin/pull/30967#pullrequestreview-2328742682)
Code review ACK fa7c2c9f18f5468baf81c04177b75e2b684a327a
💬 ryanofsky commented on pull request "refactor: Replace g_genesis_wait_cv with m_tip_block_cv":
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775515667)
re: https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775163810
I think Cory's suggestion could be implemented here with:
```diff
--- a/src/node/interfaces.cpp
+++ b/src/node/interfaces.cpp
@@ -940,17 +940,11 @@ public:
BlockRef waitTipChanged(uint256 current_tip, MillisecondsDouble timeout) override
{
- // Interrupt check interval
- const MillisecondsDouble tick{1000};
- auto now{std::chrono::steady_clock::now()};
- const auto dea
...
(https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775515667)
re: https://github.com/bitcoin/bitcoin/pull/30967#discussion_r1775163810
I think Cory's suggestion could be implemented here with:
```diff
--- a/src/node/interfaces.cpp
+++ b/src/node/interfaces.cpp
@@ -940,17 +940,11 @@ public:
BlockRef waitTipChanged(uint256 current_tip, MillisecondsDouble timeout) override
{
- // Interrupt check interval
- const MillisecondsDouble tick{1000};
- auto now{std::chrono::steady_clock::now()};
- const auto dea
...
📝 theuni opened a pull request: "build: Add missing USDT header dependency to kernel"
(https://github.com/bitcoin/bitcoin/pull/30970)
Noticed while testing a branch that replaces `boost::multi_index` with a custom replacement.
Currently depends builds pick up usdt and boost from the same path, and because boost always exists, the usdt path is implicitly included. So without boost, USDT isn't found.
An alternative to this would be to disable USDT for the kernel. I'd be open to either approach.
(https://github.com/bitcoin/bitcoin/pull/30970)
Noticed while testing a branch that replaces `boost::multi_index` with a custom replacement.
Currently depends builds pick up usdt and boost from the same path, and because boost always exists, the usdt path is implicitly included. So without boost, USDT isn't found.
An alternative to this would be to disable USDT for the kernel. I'd be open to either approach.
💬 theuni commented on pull request "build: Add missing USDT header dependency to kernel":
(https://github.com/bitcoin/bitcoin/pull/30970#issuecomment-2374557476)
Ping @hebasto @TheCharlatan
(https://github.com/bitcoin/bitcoin/pull/30970#issuecomment-2374557476)
Ping @hebasto @TheCharlatan
💬 ryanofsky commented on pull request "multiprocess: Add IPC wrapper for Mining interface":
(https://github.com/bitcoin/bitcoin/pull/30510#issuecomment-2374559335)
@Sjors did you re-ack the right commit hash in https://github.com/bitcoin/bitcoin/pull/30510#issuecomment-2373443353? (ACK is a for a commit that was replaced about 12 hours before the comment)
(https://github.com/bitcoin/bitcoin/pull/30510#issuecomment-2374559335)
@Sjors did you re-ack the right commit hash in https://github.com/bitcoin/bitcoin/pull/30510#issuecomment-2373443353? (ACK is a for a commit that was replaced about 12 hours before the comment)
🤔 theuni reviewed a pull request: "init: Remove retry for loop"
(https://github.com/bitcoin/bitcoin/pull/30968#pullrequestreview-2328825567)
Concept ACK. I've also spent a good amount of time (more than once) scratching my head trying to understand this loop.
(https://github.com/bitcoin/bitcoin/pull/30968#pullrequestreview-2328825567)
Concept ACK. I've also spent a good amount of time (more than once) scratching my head trying to understand this loop.