ipc, refactor: Update mp::g_thread_context references
What the developer wrote
Authored by Ryan Ofsky
ipc, refactor: Update mp::g_thread_context references
Use new CurrentThread function to be compatible with windows mingw bug
workaround https://github.com/bitcoin-core/libmultiprocess/pull/318
What changed, and why it matters
This is a small internal code cleanup in Bitcoin Core's inter-process communication (IPC) code. It replaces direct references to a global thread-local variable with a helper function so the code works around a compiler bug in Windows MinGW builds. There is no indication this fixes a security vulnerability or changes behavior on supported platforms.
No security action required. Treat as routine maintenance/refactor. If reviewing libmultiprocess PR #318, verify the MinGW workaround does not introduce thread-local initialization issues, but that is outside the scope of this Bitcoin Core commit.
Security signals we found
No security-relevant code change identified
Refactor only: replaces direct global variable access with inline wrapper
Commit message describes motivation as compiler compatibility, not security
No changes to validation, cryptography, networking, or consensus logic
Evidence from the diff
The commit refactors usage of mp::g_thread_context to go through a new mp::CurrentThread() wrapper. The wrapper is introduced in src/ipc/util.h and simply returns g_thread_context. The stated purpose is compatibility with a Windows MinGW bug workaround in libmultiprocess PR #318. The fuzz test is updated to call CurrentThread() to ensure the thread-local ThreadContext is initialized before IPC setup so destruction order remains correct. No functional or security-relevant change is evident from the diff.
Changed components
src/ipc/util.hsrc/ipc/capnp/protocol.cppsrc/ipc/test/fuzz/ipc.cppInspect captured patch +12 / −5
diff --git a/src/ipc/capnp/protocol.cpp b/src/ipc/capnp/protocol.cpp
index 64b1e9a9..e7eaf643 100644
--- a/src/ipc/capnp/protocol.cpp
+++ b/src/ipc/capnp/protocol.cpp
@@ -94,7 +94,7 @@ public:
void serve(interfaces::Init& init, const std::function<mp::Stream()>& make_stream) override
{
assert(!m_loop);
- mp::g_thread_context.thread_name = mp::ThreadName(m_exe_name);
+ mp::CurrentThread().thread_name = mp::ThreadName(m_exe_name);
mp::LogOptions opts = {
.log_fn = IpcLogFn,
.log_level = GetRequestedIPCLogLevel()
diff --git a/src/ipc/test/fuzz/ipc.cpp b/src/ipc/test/fuzz/ipc.cpp
index 1c19faf2..5935e9af 100644
--- a/src/ipc/test/fuzz/ipc.cpp
+++ b/src/ipc/test/fuzz/ipc.cpp
@@ -5,6 +5,7 @@
#include <primitives/transaction.h>
#include <capnp/capability.h>
#include <capnp/rpc.h>
+#include <ipc/util.h>
#include <kj/memory.h>
#include <mp/proxy-io.h>
#include <mp/proxy.h>
@@ -78,10 +79,10 @@ static void initialize_ipc()
static const auto testing_setup = MakeNoLogFileContext<>();
(void)testing_setup;
- // Ensure g_thread_context is destroyed after the IPC setup, since C++
- // destroys thread_local objects in reverse construction order.
- mp::ThreadContext& thread_context{mp::g_thread_context};
- (void)thread_context;
+ // Ensure the thread's ThreadContext is created before the IPC setup, so
+ // it is destroyed after it, since C++ destroys thread_local objects in
+ // reverse construction order.
+ mp::CurrentThread();
thread_local static IpcFuzzSetup ipc; // NOLINT(bitcoin-nontrivial-threadlocal)
g_ipc = &ipc;
diff --git a/src/ipc/util.h b/src/ipc/util.h
index 3fd3ff16..6352f981 100644
--- a/src/ipc/util.h
+++ b/src/ipc/util.h
@@ -12,6 +12,7 @@
#include <cstdint>
#include <functional>
#include <kj/debug.h>
+#include <mp/proxy-io.h>
#include <mp/util.h>
#include <mp/version.h>
#include <sys/socket.h>
@@ -52,6 +53,11 @@ inline SocketId StartSpawned(const std::string& connect_info)
if (!socket) throw std::invalid_argument(strprintf("Invalid socket descriptor '%s'", connect_info));
return *socket;
}
+
+inline ThreadContext& CurrentThread()
+{
+ return g_thread_context;
+}
#endif
} // namespace mp
Why this scored 13/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.