interprocess gives Rust one API for local sockets and pipes

One interface over OS-specific primitives

interprocess is described as an interprocess communication library for Rust programs that aims to expose as many platform specific features as possible while maintaining a uniform interface for all platforms and encouraging portable, correct code. That sentence is the whole design brief, and it explains both the value and the constraint. The value is that a Windows developer and a Linux developer can use the same call to open a local socket, and the same code compiles on both, without each of them having to remember which of the four primitives their platform actually implements. The constraint is that uniformity has a cost, and the crate is candid about where it pays it. Platform-specific extensions are put behind cfg gates and only exposed on the platforms that support them, which the documentation frames as a feature: on a platform without support, you get a compile error rather than a runtime error. A crate that chose runtime fallbacks instead would be more forgiving to write and much more annoying to debug.

The four primitives and when each one fits

The library provides both OS-specific IPC interfaces and cross-platform abstractions, and the README summarises which primitives exist and when they are useful. Local sockets are the flagship feature, described as a much more appropriate alternative to localhost TCP sockets, with better performance and developer and user friendly identifiers and authentication, and the documentation tells you that if you want two processes talking to each other and are unsure where to start, you should head to the local_socket module first because it is in all likelihood the primitive you are looking for. Unnamed pipes are there for when the pipes created by std::process are not sufficient. FIFO files on Unix are of marginal utility outside shell scripting but necessary to communicate with programs that insist on using them. Named pipes on Windows are the conventional counterpart to Unix domain sockets, and they are what local sockets are implemented with on that platform. The summary is a useful design guide even if you only use one of them.

What 2.0.0 removed and why it matters

Two removals in version 2.0.0 shaped the crate and are worth understanding before you design around it. The first-party Unix domain socket support that was present in Interprocess 1.x was removed in favour of the support provided by the standard library. The crate still uses Unix domain sockets in the Unix implementation of local sockets, but now it has the standard library types in its public API, which the documentation says enhances interoperability. In practice that means you no longer get a bespoke socket type for Unix, you get the std one, and the abstraction sits above it. The second removal is the os::unix::signal module, and the reasoning given is the interesting part: it was removed because it encouraged placement of signal handling logic into the highly perilous signal service routine context itself. The recommended replacement is the signal-hook crate, which provides a completely safe API for handling signals without writing code that executes in signal service routine context. Both removals point the same way. The crate is trying to be the IPC layer and to push adjacent, dangerous territory elsewhere.

Async support is Tokio only, and that is a deliberate limit

The asynchronous I/O section is short and sets a hard boundary. Currently, the only supported async runtime is Tokio. Local sockets and Windows named pipes are provided by Interprocess, while Unix domain sockets are available in Tokio itself. Support for smol is described as possible and desirable, but not being actively worked on. For a team already on Tokio this is unremarkable, since the crate's own dependency on tokio 1.36 is optional and gated behind the tokio feature. For a team on any other executor, or on no executor at all, it is a real constraint on adoption, and the smol situation means you cannot argue that support is imminent. The feature structure in the manifest is simple enough to read at a glance. The default feature set is empty, async pulls in futures-core, tokio pulls in dep:tokio plus async, and doc_cfg is a separate switch.

Five levels of platform support, and the compile-error bargain

Platform coverage is documented with an unusual care that is worth reading in full, because it tells you how much confidence to place in a given target. The levels are deliberately not called tiers, to prevent confusion with Rust target tiers, since those work completely differently. Explicit support covers Windows, Linux and macOS, where the crate is guaranteed to compile and succeed in running all tests, and CI from GitHub Actions runs on all of them and shows a red badge if anything is wrong. Explicit support with incomplete CI covers FreeBSD and Android, where GitHub Actions only allows Clippy and Rustdoc to run via cross-compilation because native VMs are unavailable. Explicit support without CI covers OpenBSD and NetBSD, where manual testing on local VMs is usually done before a release because the standard library rlibs cannot be installed with rustup target add. Support by association covers Dragonfly BSD, Redox, Fuchsia, iOS, tvOS and watchOS, where certain features that originate elsewhere are exposed because they behave identically. Assumed support is any cfg(unix) system not listed where libc compiles, which is an open set with no reference implementation and therefore no testing at all. A demotion would be a breaking change, while a promotion can happen in a minor or patch release.

Installing from crates.io and starting with local sockets

There is no install script to run, because this is a library rather than a tool. The package is published to crates.io under the name interprocess, with documentation on docs.rs, and the manifest names the version 2.4.6 with edition 2021 and a minimum supported Rust version of 1.75. Adding it to a project is a matter of declaring the dependency in your Cargo.toml, and the crate ships with no required features, so the default build pulls in nothing extra. The README points to the local_socket module as the place to start reading, and the repository ships runnable examples for each of the three main areas, in the examples/local_socket, examples/named_pipe and examples/unnamed_pipe directories. The examples are the fastest way to see a working pair of communicating processes, and because the same source builds on both Windows and Unix, an example is a reasonable template for your own pair.

Licensing, packaging and the dependency footprint

The crate is dual licensed. The manifest records license as 0BSD OR Apache-2.0, and the repository carries both LICENSE-0BSD.txt and LICENSE-APACHE.txt, so you can take either. The 0BSD option is about as permissive as a licence gets, requiring nothing beyond keeping the copyright notice, and the Apache-2.0 option adds the familiar patent grant and NOTICE handling. Neither obligation is a burden for a service that links the crate. The dependency footprint is deliberately small. The only hard dependencies are doctest-file 1.0.0 for the documentation tests, with futures-core 0.3.28 optional behind the async feature, tokio 1.36 optional behind the tokio feature, and the platform crates windows-sys 0.61.0 on Windows and libc 0.2.183 on Unix. A crate that wraps OS primitives is exactly the kind of project where a heavy dependency tree would be a liability, and this one keeps the tree to the standard library plus a couple of thin bindings. The release history is steady rather than bursty, with 2.4.4 on 2026-09-03, 2.4.5 on 2026-10-10 and 2.4.6 on 2026-10-16, and the last push to the repository was on 2026-10-16.

Editorial conclusion

Adopt interprocess if you are writing Rust that must talk between processes on both Windows and Unix, and you want one API surface rather than a cfg maze over the standard library. Do not adopt it if you only need a child process pipe, since std::process already covers that, or if you need Unix domain sockets, because the crate removed its own implementation in 2.0.0 in favour of the standard library. Verify two things before you commit: that the platform-specific features you need are behind a cfg gate on a platform where they exist, so a missing feature becomes a compile error rather than a runtime surprise, and that the async story matches your runtime, because the only supported async runtime is Tokio. The practical first step is to add interprocess to your project, start from the local_socket module as the documentation suggests, and check that your target platform appears in the support levels the README lists.

Frequently asked questions

Official sources

1. Issues
2. kotauskas/interprocess on GitHub
3. License: 0BSD
4. README
5. Releases