Replace boost signals with minimal compatible implementation

theuni commented at 9:27 pm on February 3, 2026: member

This drops our dependency on boost::signals2, leaving boost::multi_index as the only remaining boost dependency for bitcoind.

boost::signals2 is a complex beast, but we only use a small portion of it. Namely: it’s a way for multiple subscribers to connect to the same event, and the ability to later disconnect individual subscribers from that event.

btcsignals adheres to the subset of the boost::signals2 API that we currently use, and thus is a drop-in replacement. Rather than implementing a complex slot tracking class that we never used anyway (and which was much more useful in the days before std::function existed), callbacks are simply wrapped directly in std::functions.

The new tests work with either boost::signals2 or the new btcsignals implementation. Reviewers can verify functional equivalency by running the tests in the commit that introduces them against boost::signals2, then again with btcsignals.

The majority of the commits in this PR are preparation and cleanup. Once boost::signals2 is no longer needed, it is removed from depends. Additionally, a few CMake targets no longer need boost includes as they were previously only required for signals.

I think this is actually pretty straightforward to review. I kept things simple, including keeping types unmovable/uncopyable where possible rather than trying to define those semantics. In doing so, the new implementation has even fewer type requirements than boost, which I believe is due to a boost bug. I’ve opened a PR upstream for that to attempt to maintain parity between the implementations.

See individual commits for more details.

Closes #26442.

signals: Use a lambda to avoid connecting a signal to another signal

This is undocumented and unspecified Boost behavior that happens to work as
intended for now, but could break at any point in the future.

See the boost discussion here: https://groups.google.com/g/boost-list/c/So4i8JXneJ0

It also complicates a potential replacement of Boost::signals2.

fd5e9d9904

signals: Temporarily add boost headers to bitcoind and bitcoin-node builds

The current code forward-declares boost::signals2, which avoids the need for
these includes.

An upcoming commit will (temporarily) include boost headers directly instead.

A follow-up commit will then replace boost with an internal signals
implementation, which will allow this commit to be reverted.

2150153f37

DrahtBot commented at 9:28 pm on February 3, 2026: contributor

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
Concept ACK	fanquake, fjahr, hebasto

If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#34038 (logging: replace -loglevel with -trace, various API improvements by ajtowns)
#33117 (Interfaces: Expose UTXO Snapshot Loading and Add Progress Notifications by D33r-Gee)
#31425 (RFC: Riscv bare metal CI job by sedited)

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.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

excecuted -> executed [misspelling in test comment makes the sentence harder to read]

2026-02-05 16:23:12

theuni force-pushed on Feb 3, 2026

DrahtBot added the label CI failed on Feb 3, 2026

DrahtBot commented at 10:21 pm on February 3, 2026: contributor

🚧 At least one of the CI tasks failed. Task 32 bit ARM: https://github.com/bitcoin/bitcoin/actions/runs/21648523714/job/62408637704 LLM reason (✨ experimental): btcsignals_tests thread_safety test failed (assertion !sig0.empty()), causing the CI job to abort.

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

in src/wallet/wallet.cpp:3554 in fd5e9d9904 outdated

3548@@ -3549,7 +3549,9 @@ bool CWallet::HaveCryptedKeys() const
3549 void CWallet::ConnectScriptPubKeyManNotifiers()
3550 {
3551     for (const auto& spk_man : GetActiveScriptPubKeyMans()) {
3552-        spk_man->NotifyCanGetAddressesChanged.connect(NotifyCanGetAddressesChanged);
3553+        spk_man->NotifyCanGetAddressesChanged.connect([this] {
3554+            NotifyCanGetAddressesChanged();
3555+        });

davidgumberg commented at 10:35 pm on February 3, 2026:

In https://github.com/bitcoin/bitcoin/pull/34495/changes/fd5e9d990431a6af08dd99b25d1e17c6c9818b4d (signals: Use a lambda to avoid connecting a signal to another signal) Just observation: this fixes ~~#26422~~ #26442

hebasto commented at 11:00 pm on February 3, 2026:

Just observation: this fixes #26422

#26422 ?

davidgumberg commented at 11:06 pm on February 3, 2026:

Sorry: #26442

in src/btcsignals.h:1 in 91b1ff9eb7 outdated

0@@ -1,15 +1,268 @@
1-// Copyright (c) 2009-2010 Satoshi Nakamoto
2-// Copyright (c) 2009-2021 The Bitcoin Core developers
3+// Copyright (c) The Bitcoin Core developers

davidgumberg commented at 10:42 pm on February 3, 2026:

nit: The copyright notice is introduced in https://github.com/bitcoin/bitcoin/pull/34495/changes/f7ec999db41c54c058ab3b35bf37f52b0292e020 (signals: use forwarding header for boost signals) and then fixed in https://github.com/bitcoin/bitcoin/pull/34495/changes/91b1ff9eb7bde5e0e9d178ab8373d9dff8328000 (signals: Add a simplified boost-compatible implementation)

fanquake commented at 9:32 am on February 4, 2026: member

Concept ACK

fanquake commented at 9:32 am on February 4, 2026: member

https://github.com/bitcoin/bitcoin/actions/runs/21650096364/job/62412240316?pr=34495#step:11:581:

0[80](https://github.com/bitcoin/bitcoin/actions/runs/21650096364/job/62412240316?pr=34495#step:11:581)
1D:\a\bitcoin\bitcoin\src\node\interface_ui.cpp(28,18): fatal error C1001: Internal compiler error. [D:\a\bitcoin\bitcoin\build\src\bitcoin_node.vcxproj]
2  bitcoin_wallet.vcxproj -> D:\a\bitcoin\bitcoin\build\lib\Release\bitcoin_wallet.lib
3  (compiler file 'msc1.cpp', line 1589)
4   To work around this problem, try simplifying or changing the program near the locations listed above.
5  If possible please provide a repro here: https://developercommunity.visualstudio.com/ 
6  Please choose the Technical Support command on the Visual C++ 
7   Help menu, or open the Technical Support help file for more information
8  INTERNAL COMPILER ERROR in 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe'

fanquake commented at 10:47 am on February 4, 2026: member

This also prunes half a megabyte off the size of a Guix built (stripped) bitcoind. master (1e64aeaaecc2)

0/bitcoin/guix-build-1e64aeaaecc2/output/x86_64-linux-gnu/bitcoin-1e64aeaaecc2/bin# ls -lah *
11.9M bitcoin
22.5M bitcoin-cli
339.3M bitcoin-qt
44.6M bitcoin-tx
54.2M bitcoin-util
68.8M bitcoin-wallet
715.4M bitcoind

This PR (7f7df4102bea867a7826ddfa38955f6ed4697ea6 rebased on master):

0/bitcoin/guix-build-75e0b3349c5d/output/x86_64-linux-gnu/bitcoin-75e0b3349c5d/bin# ls -lah *
11.9M bitcoin
22.5M bitcoin-cli
338.8M bitcoin-qt
44.6M bitcoin-tx
54.2M bitcoin-util
68.6M bitcoin-wallet
714.9M bitcoind

fjahr commented at 11:07 am on February 4, 2026: contributor

Concept ACK

theuni commented at 3:08 pm on February 4, 2026: member

https://github.com/bitcoin/bitcoin/actions/runs/21650096364/job/62412240316?pr=34495#step:11:581:

0[80](https://github.com/bitcoin/bitcoin/actions/runs/21650096364/job/62412240316?pr=34495#step:11:581)
1D:\a\bitcoin\bitcoin\src\node\interface_ui.cpp(28,18): fatal error C1001: Internal compiler error. [D:\a\bitcoin\bitcoin\build\src\bitcoin_node.vcxproj]
2  bitcoin_wallet.vcxproj -> D:\a\bitcoin\bitcoin\build\lib\Release\bitcoin_wallet.lib
3  (compiler file 'msc1.cpp', line 1589)
4   To work around this problem, try simplifying or changing the program near the locations listed above.
5  If possible please provide a repro here: https://developercommunity.visualstudio.com/ 
6  Please choose the Technical Support command on the Visual C++ 
7   Help menu, or open the Technical Support help file for more information
8  INTERNAL COMPILER ERROR in 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe'

@hebasto Any experience dealing with MSVC ICE’s?

This is frustrating considering how much simpler it is than boost.

l0rinc commented at 4:37 pm on February 4, 2026: contributor

INTERNAL COMPILER ERROR

Can we replace Windows with a minimal compatible implementation as well?

hodlinator commented at 10:07 pm on February 4, 2026: contributor

I’m able to build 237005aa7579be4488696bdca28253e8216453a9 “signals: add signals tests” fine, but the following commit, 91b1ff9eb7bde5e0e9d178ab8373d9dff8328000 “signals: Add a simplified boost-compatible implementation” has a lot of failures. Some can be fixed by adding

0#include <boost/signals2/signal.hpp>

to /src/wallet/scriptpubkeyman.h.

But after fixing that, ICE’s show up together with more easily actionable issues:

 0C:\Users\hodlinator\bitcoin\src\node\interface_ui.cpp(28,18): fatal error C1001: Internal compiler error. [C:\Users\hodlinator\bitcoin\build\src\bitcoin_node.vcxproj]
 1  (compiler file 'msc1.cpp', line 1589)
 2   To work around this problem, try simplifying or changing the program near the locations listed above.
 3  If possible please provide a repro here: https://developercommunity.visualstudio.com
 4  Please choose the Technical Support command on the Visual C++
 5   Help menu, or open the Technical Support help file for more information
 6  INTERNAL COMPILER ERROR in 'C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe'
 7      Please choose the Technical Support command on the Visual C++
 8      Help menu, or open the Technical Support help file for more information
 9C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(505,16): error C2664: 'std::unique_ptr<interfaces::Handler,std::default_delete<interfaces::Handler>> interfaces::MakeSignalHandler(btcsignals::connection)': cannot conver
10t argument 1 from 'boost::signals2::connection' to 'btcsignals::connection' [C:\Users\hodlinator\bitcoin\build\src\wallet\bitcoin_wallet.vcxproj]
11      C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(505,64):
12      No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
13      C:\Users\hodlinator\bitcoin\src\interfaces\handler.h(28,26):
14      see declaration of 'interfaces::MakeSignalHandler'
15      C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(505,16):
16      while trying to match the argument list '(boost::signals2::connection)'
17
18C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(509,16): error C2664: 'std::unique_ptr<interfaces::Handler,std::default_delete<interfaces::Handler>> interfaces::MakeSignalHandler(btcsignals::connection)': cannot conver
19t argument 1 from 'boost::signals2::connection' to 'btcsignals::connection' [C:\Users\hodlinator\bitcoin\build\src\wallet\bitcoin_wallet.vcxproj]
20      C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(509,64):
21      No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
22      C:\Users\hodlinator\bitcoin\src\interfaces\handler.h(28,26):
23      see declaration of 'interfaces::MakeSignalHandler'
24      C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(509,16):
25      while trying to match the argument list '(boost::signals2::connection)'
26
27C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(513,16): error C2664: 'std::unique_ptr<interfaces::Handler,std::default_delete<interfaces::Handler>> interfaces::MakeSignalHandler(btcsignals::connection)': cannot conver
28t argument 1 from 'boost::signals2::connection' to 'btcsignals::connection' [C:\Users\hodlinator\bitcoin\build\src\wallet\bitcoin_wallet.vcxproj]
29      C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(513,71):
30      No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
31      C:\Users\hodlinator\bitcoin\src\interfaces\handler.h(28,26):
32      see declaration of 'interfaces::MakeSignalHandler'
33      C:\Users\hodlinator\bitcoin\src\wallet\interfaces.cpp(513,16):
34      while trying to match the argument list '(boost::signals2::connection)'

Would focus on fixing the non-ICE issues in that commit.

I think there has been some work with failing faster, hopefully you still see the other errors on CI.

theuni commented at 10:56 pm on February 4, 2026: member

@hodlinator At 91b1ff9eb7bde5e0e9d178ab8373d9dff8328000, boost is no longer used, so including that header won’t help anything. I’m not sure how it’s even picking up boost::signals2 references anymore. Is it possible something is stale in your environment? Whatever errors you’re seeing without including that header would be the interesting ones.

But don’t poke too hard just yet. I realized last night that there’s a behavioral break from boost in this branch, in that callbacks are not allowed to modify their signal or connection. If attempted, the callback will deadlock.

I’ve updated the approach to match boost’s model on this branch: https://github.com/theuni/bitcoin/tree/replace-signals-recursive . I’m just waiting to see how the c-i looks before force-pushing it here.

Apologies to anyone who’s reviewed so far, hopefully nobody has looked into it too deeply. I’ve added some extra tests to demonstrate what would’ve deadlocked with the previous approach.

theuni force-pushed on Feb 4, 2026

theuni commented at 11:49 pm on February 4, 2026: member

I realized last night that there’s a behavioral break from boost in this branch, in that callbacks are not allowed to modify their signal or connection. If attempted, the callback will deadlock.

I’ve updated the approach to match boost’s model on this branch: https://github.com/theuni/bitcoin/tree/replace-signals-recursive . I’m just waiting to see how the c-i looks before force-pushing it here.

Apologies to anyone who’s reviewed so far, hopefully nobody has looked into it too deeply. I’ve added some extra tests to demonstrate what would’ve deadlocked with the previous approach.

Pushed an updated impl of btcsignals which matches boost’s callback threading model. Sorry for the noise.

theuni force-pushed on Feb 4, 2026

maflcko commented at 6:10 am on February 5, 2026: member

@hebasto Any experience dealing with MSVC ICE’s?

I think they try to fix them within the next two releases, if reported. Minimizing will likely help, but I guess creduce doesn’t work on Windows, so someone would have to do this manually. Maybe an LLM could be taught to behave like creduce? (I tried that once, but gave up rather quickly)

hodlinator commented at 8:14 am on February 5, 2026: contributor

Likewise, sorry for the noise, I don’t know what happened to my local Windows repo.

hodlinator commented at 10:02 am on February 5, 2026: contributor

Managed to boil down the ICE, would someone else please do the honors of reporting to MS?

C++-file:

 0#include <mutex>
 1
 2struct MutexChild : public std::mutex {
 3    // No ICE: ~MutexChild() = default;
 4    ~MutexChild() {}
 5};
 6
 7struct ice_signal {
 8    MutexChild m_mutex{};
 9};
10
11ice_signal s;

Command line:

0"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe" /std:c++20 path_to_file.cpp

Note that dropping /std:c++20 makes it avoid the ICE.

maflcko commented at 10:12 am on February 5, 2026: member

Managed to boil down the ICE, would someone else please do the honors of reporting to MS?

Excellent reproducer. I’ll report it

maflcko commented at 10:28 am on February 5, 2026: member

https://developercommunity.visualstudio.com/t/C1001:-Internal-compiler-error-Using-st/11039556

in src/btcsignals.h:245 in 956ea69802

240+            }
241+        }
242+        return true;
243+    }
244+
245+    mutable Mutex m_mutex{};

hodlinator commented at 10:31 am on February 5, 2026:

I know it’s blasphemous but switching to RecursiveMutex/AnnotatedMixin<std::recursive_mutex> avoids the ICE on native Windows for some reason:

0    mutable RecursiveMutex m_mutex{};

Found while figuring out the ICE reproducer.

maflcko commented at 10:39 am on February 5, 2026:

Maybe guard the RecursiveMutex behind #if defined(_MSC_VER)?

hebasto commented at 3:17 pm on February 5, 2026:

Or stop using MSVC?

hebasto referenced this in commit eb97250421 on Feb 5, 2026

hebasto commented at 2:35 pm on February 5, 2026: member

https://developercommunity.visualstudio.com/t/C1001:-Internal-compiler-error-Using-st/11039556

Please vote!

in depends/packages/boost.mk:9 in 956ea69802 outdated

 5@@ -6,7 +6,7 @@ $(package)_sha256_hash = 913ca43d49e93d1b158c9862009add1518a4c665e7853b349a6492d
 6 $(package)_build_subdir = build
 7 
 8 define $(package)_set_vars
 9-  $(package)_config_opts = -DBOOST_INCLUDE_LIBRARIES="multi_index;signals2;test"
10+  $(package)_config_opts = -DBOOST_INCLUDE_LIBRARIES="multi_index;test"

hebasto commented at 2:53 pm on February 5, 2026:

And from vcpkg:

0--- a/vcpkg.json
1+++ b/vcpkg.json
2@@ -4,7 +4,6 @@
3   "builtin-baseline": "120deac3062162151622ca4860575a33844ba10b",
4   "dependencies": [
5     "boost-multi-index",
6-    "boost-signals2",
7     "libevent"
8   ],
9   "default-features": [

hebasto commented at 3:15 pm on February 5, 2026: member

https://github.com/bitcoin/bitcoin/actions/runs/21650096364/job/62412240316?pr=34495#step:11:581:

0[80](https://github.com/bitcoin/bitcoin/actions/runs/21650096364/job/62412240316?pr=34495#step:11:581)
1D:\a\bitcoin\bitcoin\src\node\interface_ui.cpp(28,18): fatal error C1001: Internal compiler error. [D:\a\bitcoin\bitcoin\build\src\bitcoin_node.vcxproj]
2  bitcoin_wallet.vcxproj -> D:\a\bitcoin\bitcoin\build\lib\Release\bitcoin_wallet.lib
3  (compiler file 'msc1.cpp', line 1589)
4   To work around this problem, try simplifying or changing the program near the locations listed above.
5  If possible please provide a repro here: https://developercommunity.visualstudio.com/ 
6  Please choose the Technical Support command on the Visual C++ 
7   Help menu, or open the Technical Support help file for more information
8  INTERNAL COMPILER ERROR in 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe'

@hebasto Any experience dealing with MSVC ICE’s?

This is frustrating considering how much simpler it is than boost.

Let’s switch to clang-cl.

The CI log is available here: https://github.com/hebasto/bitcoin/actions/runs/21716329966/job/62633207718.

theuni commented at 4:12 pm on February 5, 2026: member

Managed to boil down the ICE, would someone else please do the honors of reporting to MS?

C++-file:

 0#include <mutex>
 1
 2struct MutexChild : public std::mutex {
 3    // No ICE: ~MutexChild() = default;
 4    ~MutexChild() {}
 5};
 6
 7struct ice_signal {
 8    MutexChild m_mutex{};
 9};
10
11ice_signal s;

Command line:

0"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe" /std:c++20 path_to_file.cpp

Note that dropping /std:c++20 makes it avoid the ICE.

Thanks so much!

But.. I don’t understand. This is just a vanilla use of our Mutex type. If that’s the reproducer, why doesn’t this cause an ICE everywhere else in our codebase?

theuni commented at 4:17 pm on February 5, 2026: member

Managed to boil down the ICE, would someone else please do the honors of reporting to MS? C++-file:
 0#include <mutex>
 1
 2struct MutexChild : public std::mutex {
 3    // No ICE: ~MutexChild() = default;
 4    ~MutexChild() {}
 5};
 6
 7struct ice_signal {
 8    MutexChild m_mutex{};
 9};
10
11ice_signal s;
Command line:
0"C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe" /std:c++20 path_to_file.cpp
Note that dropping /std:c++20 makes it avoid the ICE.
Thanks so much!

But.. I don’t understand. This is just a vanilla use of our Mutex type. If that’s the reproducer, why doesn’t this cause an ICE everywhere else in our codebase?

Aha! It’s the initializer! I added it to make clang-tidy happy, but MSVC apparently doesn’t like it. No worries, I’ll just remove it.

Bad:

0struct ice_signal {
1    MutexChild m_mutex{};
2};

Good:

0struct ice_signal {
1    MutexChild m_mutex;
2};

signals: use forwarding header for boost signals

For now, including btcsignals.h simply includes boost's signals. A follow-up
commit will replace the implementation.

037e58b57b

signals: remove forward-declare for signals

This eases the transition to a replacement signals implementation

9ade3929aa

signals: use an alias for the boost::signals2 namespace

The next commit will add a real implementation in this namespace.

edc2978058

signals: add signals tests

These tests are compatible with boost::signals2 as well as the replacement
implementation that will be introduced in the next commit.

This is intended to demonstrate some equivalency between the implementations.

1260a917b7

signals: Add a simplified boost-compatible implementation

This re-implements the tiny portion of boost::signals2 that we currently use.

It is enough to be useful as a generic multicast callback mechanism.

81e6708d27

signals: remove unnecessary move assignment operator for tests

This was necessary to work around an unnecessary boost constraint.

Using our own implementation instead, this causes a warning because it's
unused.

5575d1808d

Revert "signals: Temporarily add boost headers to bitcoind and bitcoin-node builds"

This reverts commit 3df1a1405972076384946c71c45bb056cfdf8c41.

This was only necessary as an interim workaround.

f8e97b92f1

signals: re-add forward-declares to interface headers

The real includes were only needed temporarily while supporting btcsignals as
an alias for boost::signals2.

c4ecd49ae5

signals: remove boost includes where possible

In both of these cases, boost was only needed for signals and not for
multi_index/test.

424cfb691c

signals: remove boost::signals2 mentions in linters and docs

The documented example is no longer relevant, so remove it rather than updating
it to mention btcsignals.

32daae0b7a

signals: remove boost::signals2 from depends and vcpkg 5e088b91b2

theuni force-pushed on Feb 5, 2026

theuni commented at 4:26 pm on February 5, 2026: member

In latest push:

Fixed ICE (I hope)
Removed from vcpkg (thanks @hebasto)
Fixed copyright header nit (thanks @davidgumberg)

hebasto commented at 4:38 pm on February 5, 2026: member

Concept ACK.

DrahtBot removed the label CI failed on Feb 5, 2026

fanquake commented at 10:03 pm on February 6, 2026: member

Upstream change has landed: https://github.com/boostorg/signals2/pull/85.

in src/btcsignals.h:245 in 5e088b91b2

240+            }
241+        }
242+        return true;
243+    }
244+
245+    mutable Mutex m_mutex;

w0xlt commented at 0:50 am on February 13, 2026:

It seems m_mutex and m_connections don’t need to be exposed.

0private:
1    mutable Mutex m_mutex;

theuni commented at 0:59 am on February 13, 2026:

Whoops, nice catch! This must’ve gotten lost somewhere along the way. Will fix.

in src/btcsignals.h:151 in 5e088b91b2

146+    /*
147+     * Helper struct for maintaining a callback and its associated connection
148+     */
149+    struct connection_holder {
150+        template <typename Callable>
151+        connection_holder(Callable&& callback) noexcept : m_callback{std::forward<Callable>(callback)}

w0xlt commented at 0:50 am on February 13, 2026:

nit: Can m_callback (std::function) allocation throw ?

0        connection_holder(Callable&& callback) : m_callback{std::forward<Callable>(callback)}

theuni commented at 1:15 am on February 13, 2026:

No, but looking again, I suppose the callback’s move ctor could. I’ll make this change to be safe.

in src/test/btcsignals_tests.cpp:20 in 5e088b91b2

15+    moveonly_data(int data) : m_data(data){}
16+    moveonly_data(moveonly_data&&) = default;
17+
18+    moveonly_data& operator=(moveonly_data&&) = delete;
19+    moveonly_data(const moveonly_data&) = delete;
20+    moveonly_data& operator=(const moveonly_data&) = default;

w0xlt commented at 0:53 am on February 13, 2026:

0    moveonly_data& operator=(const moveonly_data&) = delete;

theuni commented at 1:16 am on February 13, 2026:

Looks right, thanks.

Replace boost signals with minimal compatible implementation #34495

Reviews

Conflicts

LLM Linter (✨ experimental)