Add nonunix platform support #274

Add ProcessId = int type alias and apply it to WaitProcess, SpawnProcess
(pid output argument), and callers.

Add SocketId = int and SocketError = -1 type aliases and apply SocketId
to SpawnProcess (return type and callback parameter) and callers.

Add ConnectInfo type alias to pass socket handle from parent process to
child process in more platform independent way.

gen.cpp used fork() directly via <unistd.h> to invoke the capnp compiler as a
subprocess, but fork() is not available on Windows, so shouldn't be used in
application code.

Add an ExecProcess(const std::vector<std::string>& args) function to
util.h/util.cpp that spawns a process and returns its ProcessId, leaving
the caller responsible for WaitProcess. On POSIX it uses fork() (via
KJ_SYSCALL) + execvp; on Windows it can use CreateProcess.

Update gen.cpp to replace the inline fork/exec/wait with
mp::WaitProcess(mp::ExecProcess(args)).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Extract socket pair creation from SpawnProcess into a standalone
SocketPair() function, and use it to replace the inline socketpair()
call. No behavior change.

Explicitly clear FD_CLOEXEC on the child's socket before calling exec,
so the fd survives into the spawned process regardless of how the socket
was created. Previously this relied on socketpair() not setting
FD_CLOEXEC by default, which is not guaranteed if the caller creates
sockets with SOCK_CLOEXEC or if the flag gets set by other means.

Replace the m_wait_fd/m_post_fd raw int members with
m_wait_stream/m_post_stream kj::Own<kj::AsyncIoStream> and
m_post_writer kj::Own<kj::OutputStream>.

The constructor uses provider->newTwoWayPipe() instead of calling
socketpair() directly. The loop() and post() methods write through
m_post_writer instead of calling write() with a raw fd, and
EventLoopRef::reset does the same.

kj::AsyncIoStream::getFd() was added in capnproto 0.9 (commit
d27bfb8a4175b32b783de68d93dd1dbafadddea5, first released in 0.9.0). The
code now uses getFd() in proxy.cpp, so 0.7 is no longer a sufficient
minimum.

Set olddeps version to 0.9.2, which is the patched 0.9.x release for
CVE-2022-46149.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Instead of accepting raw file descriptor integers and wrapping them
internally, ConnectStream and ServeStream now accept
kj::Own<kj::AsyncIoStream> directly. This removes the assumption that
the transport is always a local unix fd, making the API easier to adapt
to other I/O types (e.g. Windows handles).

The Stream type alias (kj::Own<kj::AsyncIoStream>) is added as a
convenience, along with StreamSocketId() to extract the underlying fd
from a Stream when needed.

Callers are updated to wrap their fd with wrapSocketFd() before calling.

Flush pending Cap'n Proto release messages before closing the stream.
When one side of a socket pair closes, the other side does not receive
an onDisconnect event, so it relies on receiving release messages from
the closing side to free its ProxyServer objects and shut down cleanly.
Without this, Server objects are not freed by Cap'n Proto on
disconnection.

MSVC error when building multiprocess.vcxproj:

  mp/util.h(146,46): error C2280:
    'std::variant<T *,T>::variant(const std::variant<T *,T> &)':
    attempting to reference a deleted function [with T=mp::Lock]

The PtrOrValue constructor used a ternary expression to initialize data:

  data(ptr ? ptr : std::variant<T*, T>{std::in_place_type<T>, args...})

Both arms are prvalues of type std::variant<T*,T>, so under C++17's
mandatory copy elision no copy/move constructor should be invoked. GCC
and Clang apply this correctly. MSVC does not apply guaranteed copy
elision to ternary expressions in this context: it materializes the
temporary and then attempts to copy-construct data from it. Since
std::variant<Lock*,Lock> has a deleted copy constructor (Lock holds a
std::unique_lock which is move-only), MSVC fails.

Fix by initializing data to hold T*=ptr in the member initializer list,
then emplacing T in-place in the constructor body if ptr is null. This
avoids the ternary entirely and requires only the in-place constructor
of T, not any variant copy or move.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

MSVC warns (C4305, treated as error) about truncation from 'int' to
'const bool' when initializing static const bool members from integer
bitwise-and expressions. Use constexpr bool with explicit != 0 to
make the boolean conversion unambiguous.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

MSVC cannot parse 'typename decltype(expr)::Member' syntax and fails
with a hard error (C2039, C2146) instead of a SFINAE substitution
failure. Use Decay<> wrapper to provide the extra template indirection
that MSVC needs, consistent with the unique_ptr and shared_ptr overloads
of CustomBuildField which already use this pattern.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

This repo has introduced API changes to add Windows support to
libmultiprocess (HANDLE-based IPC alongside the existing fd-based IPC).
These changes require corresponding updates to Bitcoin Core, which are
pending in bitcoin/bitcoin#35084. Until that PR merges, the Bitcoin Core
CI jobs fail against master because Bitcoin Core has not yet been updated
to use the new API.

Switch the Bitcoin Core checkout in both jobs to use
refs/pull/35084/merge so CI tests against the compatible version. A
BITCOIN_CORE_REF env var is introduced at the top of the file; once
(and keep the var in place for any future API compatibility cycles).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

On macOS, when libcapnp is built as a dynamic library and Bitcoin Core
REDUCE_EXPORT option is used the RTTI typeinfo for kj::Exception has a
different address in libcapnp.dylib versus the calling binary. This
means catch (const kj::Exception& e) in the calling binary silently
fails to match exceptions thrown by capnp, so the DISCONNECTED exception
from shutdownWrite() propagates as a fatal uncaught exception instead of
being suppressed as intended.

This causes the Bitcoin Core macOS native CI job to fail with:
  Fatal uncaught kj::Exception: kj/async-io-unix.c++:491: disconnected:
    shutdown(fd, SHUT_WR): Socket is not connected

The fix is to use kj::runCatchingExceptions/kj::throwRecoverableException,
which use KJ's own thread-level exception interception mechanism rather
than C++ RTTI-based matching, and therefore work correctly across dynamic
library boundaries. This is the same approach used elsewhere in the
codebase (proxy.cpp EventLoop::post, type-context.h server request handler)
for the same reason.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

On MSVC, std::terminate() does not print the exception message before
calling abort()/fastfail, so exceptions thrown during mpgen execution
appear as a bare 0xC0000409 exit code with no diagnostic output. Wrap
main() in a try-catch to explicitly print the error to stderr and
return 1 instead of crashing.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Bitcoin Core linter rejects it:
https://github.com/bitcoin/bitcoin/actions/runs/24568789956/job/71835997334?pr=32387

Use target_compile_definitions on mpgen to expose CAPNP_EXECUTABLE,
CAPNPC_CXX_EXECUTABLE (via $<TARGET_FILE:...> generator expressions on
the CapnProto::capnp_tool and CapnProto::capnpc_cpp imported targets),
and CAPNP_INCLUDE_DIRS (from the CAPNP_INCLUDE_DIRS variable set by
find_package). gen.cpp uses these directly instead of constructing paths
from capnp_PREFIX. Remove capnp_PREFIX from config.h.in as it is no
longer needed there. Add compat fallbacks in compat_config.cmake to
synthesize the tool imported targets and CAPNP_INCLUDE_DIRS from older
variables when using an older CapnProto package.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Ubuntu Noble's libcapnp-dev 1.0.1 cmake config file is installed under
/usr/lib/x86_64-linux-gnu/cmake/CapnProto/ but its _IMPORT_PREFIX
calculation goes up only 3 directory levels to /usr/lib instead of 4
levels to /usr, so IMPORTED_LOCATION for CapnProto::capnp_tool is set
to /usr/lib/bin/capnp (non-existent) rather than /usr/bin/capnp.

The previous compat_config.cmake fallback only fired when the target
didn't exist at all (NOT TARGET), so it didn't catch this case where
the target exists but has a wrong path.

Add a validation pass that iterates over both tool targets after they
are created (either by the package or by our own fallback). For each
target, check whether any IMPORTED_LOCATION (config-specific or
generic) resolves to an existing file. If none do, use find_program
(with capnp_PREFIX/bin as a hint) to locate the actual binary and
override all stored locations on that target.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>