Windows
Windows 11 ARM64 · UTM VM · .NET 10
| Workload · 3 B message | Mean | Allocated |
|---|---|---|
| Send | 6.26 ns | 0 B |
| Send + receive, reused buffer | 17.96 ns | 0 B |
A SHARED-MEMORY IPC LIBRARY
Interprocessv3
Fast, lightweight queues
across processes and languages.
Rust · C · Python · Node.js · Go · .NET
Connect multiple publisher and subscriber processes through a shared circular buffer. Native atomic reservations, reusable memory, and no broker service. Built for high throughput on a single machine.
Linux · macOS · Windows MIT licensed
RUST · LOCAL QUEUE BENCHMARKRelease
12.98ns
Send + receive
A complete queue round trip,
with the receive buffer reused.
- 50-byte message
- 16.05 ns
- 1,024-byte message
- 56.33 ns
3-byte message · Apple M5 MaxIn-process microbenchmark · Release build
Explore the measurements ↗
0 B
allocated per round tripMeasured .NET path with a reused buffer
0
broker servers to runThe queue lives in shared memory
2,048
publishers per queueWith multiple competing subscribers
BENCHMARKS
Queue operations,
measured in nanoseconds.
Actual queue operations, measured in Release builds. These are in-process microbenchmarks; latency between separate processes also depends on scheduling and workload.
macOS
Apple M5 Max · Native execution
| Implementation | Workload | Message | Mean | StdDev |
|---|---|---|---|---|
| Rust | Send + receive, reused buffer | 3 B | 12.98 ns | 0.18 ns |
| Rust | Send + receive, reused buffer | 50 B | 16.05 ns | 0.32 ns |
| Rust | Send + receive, reused buffer | 1,024 B | 56.33 ns | 0.83 ns |
| .NET | Send | 3 B | 5.74 ns | 0.13 ns |
| .NET | Send + receive, reused buffer | 3 B | 17.37 ns | 0.43 ns |
| .NET | Send + receive, reused buffer | 50 B | 18.81 ns | 0.23 ns |
All .NET rows above: 0 B allocated. Rust uses preallocated send and receive buffers; allocations were not separately instrumented.
Linux
Ubuntu 24.04 ARM64 · QEMU VM · .NET 10
| Workload · 3 B message | Mean | Allocated |
|---|---|---|
| Send | 6.00 ns | 0 B |
| Send + receive, reused buffer | 16.68 ns | 0 B |
Measurement details & reproducible results +
Rust: September 14, 2026, Apple M5 Max, Rust 1.98.1. One million send-and-receive operations per sample; four warmup samples and eight measured samples. A 1 MiB queue and reused receive storage. Download raw results ↗ · Benchmark source ↗
.NET: September 13, 2026, .NET 10.0.12 and BenchmarkDotNet; two launches and eight measured iterations. macOS 26.6.2 runs natively on the M5 Max. Windows uses a 4-vCPU, 12 GiB UTM VM; Linux uses a 4-vCPU, 8 GiB Lima/QEMU VM on the same Mac. Send-only tests drain outside the timed batch. Benchmark source ↗
All benchmarks keep publishers and subscribers connected throughout measurement. Queue creation and cleanup are outside the timed work. “Send” means enqueue; “receive” means dequeue. A send + receive operation sends one message and consumes it once.
Rust and .NET use separate benchmark harnesses. These results show each measured workload; they are not a controlled comparison between languages. Wrapper costs for Python, Node.js, and Go are not included in the Rust numbers.
ARCHITECTURE
Multiple publishers.
Multiple subscribers.
Publishers put messages into a shared queue. Subscribers take messages out and do the work. They can run in separate processes, in different languages, without a messaging server in the middle.
Publishers
Process A Rust
Process B Python
Process C .NET
Submit work concurrently
SHARED MEMORY
One circular bufferNo network hop. No broker process.
Subscribers
Worker A Go
Worker B Node.js
Worker C C
Share the work across workers
Many producers. Many consumers.
Each queued message is consumed by one subscriber. Add workers to share the load, connect several producers to the same queue, and keep each process focused on its job.
Transient by design.
The queue stays alive while at least one publisher or subscriber is connected. Once all are gone, the queue and unread messages are no longer available. Reusing the name starts a fresh, empty queue. Keep a subscriber connected before a short-lived publisher exits.
EFFICIENCY
Low overhead,
by design.
A small library in your application, backed by a bounded shared-memory buffer. No separate broker to provision, monitor, or keep running.
Keep allocations out
of the hot path.
Preallocate queue storage and reuse receive buffers. The measured .NET send-and-receive path allocates 0 bytes per operation, reducing garbage-collection pressure.
Move bytes with
very little work.
Native 64-bit atomic reservations and coalesced wakeups keep coordination lean. Send your existing binary format without a required serializer or wire protocol.
Keep the operating
cost small.
No additional messaging service, broker machine, or per-message license fee. Run your processes on the same host and choose how much memory the queue uses.
LANGUAGE INTERFACES
One queue.
Six language interfaces.
Rust, C, Python, Node.js, Go, and .NET can exchange messages through the same open v3 protocol. Pick the right language for each process.
Available now: .NET on NuGet, Rust on crates.io, Node.js on npm, Go, and the C SDK. Python is available from source.
Read the Rust guide →Install
PROTOCOL V3
Open source.
Documented in full.
Inspect the memory layout, atomic ordering, resource lifetime, and crash recovery. Build on an MIT-licensed implementation with tests across every publisher/subscriber language pair.
Built for volatile queues on one machine. For durable jobs, add application-level acknowledgements and persistence.
Read the protocol ↗