ipc-channel

ipc-channel extends Rust’s familiar std::sync::mpsc channel model to work between operating-system processes rather than just threads. It was built for the Servo browser engine, where a multi-process architecture needs a fast, ergonomic way to pass messages, file descriptors, and shared-memory regions between components.

Messages are serialized with Serde and transported over native OS IPC primitives — file-descriptor passing over Unix sockets, Mach ports on macOS, and named pipes on Windows — so the API stays as close to Rust channels as possible while transparently crossing process boundaries. Both senders and receivers are themselves serializable, letting you route channels over channels to bootstrap complex multi-process topologies.

What You Get

• IpcSender<T> and IpcReceiver<T> types that mirror the standard library’s channel API for a near drop-in migration
• An IpcOneShotServer for bootstrapping a channel between a parent and a freshly spawned or forked child process
• A RouterProxy/ROUTER layer that bridges IPC receivers back into ergonomic crossbeam channels and callbacks
• Shared-memory and out-of-band file-descriptor transfer for moving large payloads efficiently
• Platform backends for Unix sockets, macOS Mach ports, and Windows named pipes, plus an in-process fallback for testing

Common Use Cases

• Splitting an application into mutually untrusting processes that communicate over typed channels
• Passing file descriptors or shared-memory handles between a parent process and its workers
• Bootstrapping IPC between a spawned child process and its parent via a one-shot server name
• Bridging received IPC messages into a single-threaded event loop through the router

Under The Hood

Architecture — The public surface lives in src/ipc.rs, which defines IpcSender<T>/IpcReceiver<T>, IpcOneShotServer, IpcReceiverSet, and shared-memory types, all generic over Serde-serializable T. These delegate to a platform abstraction under src/platform/ that selects a backend at compile time via cfg gates in src/lib.rs: unix (fd passing over Unix sockets, using mio for the receiver set on Linux/BSD/illumos), macos (Mach ports), windows (named pipes), and an inprocess fallback for force-inprocess builds and testing. src/router.rs adds a RouterProxy (exposed as the global ROUTER) that spins up a background thread to demultiplex registered IPC receivers into crossbeam channels or callbacks. Messages are encoded with postcard and carried alongside out-of-band OS resources (descriptors, shared-memory segments) so large or handle-bearing payloads avoid byte-by-byte copying.

Tech Stack — Rust edition 2021 with an MSRV of 1.86. Core dependencies are crossbeam-channel (router bridging), serde_core/postcard (serialization), libc (Unix syscalls), uuid (server name generation), and thiserror (error types). Platform-specific dependencies are pulled in via cfg target gates: mio, rustc-hash, and tempfile on Linux/OpenBSD/FreeBSD/illumos; rand on macOS; and the windows crate (0.61) with Win32 pipe/memory/security features on Windows. An optional async feature adds futures-core/futures-channel.

Code Quality — Testing is substantial: src/test.rs (~30 KB) exercises cross-process sending including fork()-based scenarios, tests/integration_test.rs covers spawned-child bootstrapping, and per-platform tests live under src/platform/. Benchmarks in benches/ use Criterion. Error handling is centralized in src/error.rs with thiserror-derived IpcError, SerDeError, TryRecvError, and TrySelectError enums rather than ad-hoc strings, and the codebase is enforced through rustfmt and CI across macOS, Linux, and Windows.

API Design — The library’s defining choice is deliberate parity with std::sync::mpsc: ipc::channel(), IpcSender<T>, and IpcReceiver<T> map one-to-one onto the standard channel types, so the learning curve is mostly “the channels you already know, across processes.” Because endpoints are themselves Serialize/Deserialize, channels compose naturally over other channels, and the IpcOneShotServer gives a documented, minimal-boilerplate path for establishing the first connection to a child process. The README documents semantic differences from std channels (always unbounded, resource-consuming, serialization-based) up front, which keeps the ergonomic API from hiding its real-world tradeoffs.