IPC

Status: draft · Handles are typed, one type per kind (decided 2026-11-02) · Builds on Transports and Connections · Handles answer part of the open capabilities design · The first step of Comline for systems software

The question: what does Comline need to be a good interface between processes on one machine, beyond what a network connection needs?

Where things stand:

• The runtime calls itself an RPC/IPC runtime, but nothing designs IPC. The runtime contract lists Unix sockets and in-process among transports and stops there.
• What already suits IPC: the Rust runtime's lowest tier is no_std with no allocator; dispatch is synchronous; decoders refuse hostile lengths before allocating; generated code forbids unsafe; the shared runtime core has a C ABI.
• Connections plan peer information from the transport in each connection's state, and interceptors that can reject calls (for authorization) before they reach a handler.
• Transports is a draft: optional declarations, transport profiles with stated facts, and a "transport fit" guarantee where declared.

What makes IPC different

IPC transports

Profiles in the transports shape, with three facts IPC adds:

• handles: which kinds of handle the transport can carry, and how many per message (Linux allows 253 file descriptors per message; a Zircon channel, 64);
• peer_identity: what the OS reports about the peer;
• peer_death: whether the OS reports a peer's exit.

Handles

A handle is something the OS lets one process give another: an open file, a shared memory region, an endpoint of another channel. It travels beside the bytes, not in them.

The options

H2: a type per kind

remote and receiver are capabilities in the Cap'n Proto and Mojo sense: a call can hand the peer a new, typed connection. That's the capabilities part of the open design.

protocol Files {
    /// Opens a file and hands it to the caller.
    function open(path: char[max 4096]) -> file;
    /// Shares a frame buffer without copying it.
    function frame() -> memory[max 8388608];
    /// Gives the caller its own session, served on a new channel.
    function session() -> remote Session;
}

How they work, whichever spelling is chosen:

• On the wire, a handle is encoded as its index in the message's attachments: a u32 in packed@1, a number in json@1. The handles themselves go through the transport.
• Checked on arrival: the decoder checks each handle is the kind the schema says (fstat, zx_object_get_info and their equivalents), and that the message carries exactly the handles its body refers to. An unexpected or wrong handle is refused, and closed.
• Ownership moves: sending a handle gives it away; the sender keeps a copy only by duplicating it first. A received handle is owned by the receiver. Every handle in a refused message is closed, so nothing leaks.
• Bounded like everything else: an array of handles needs a maximum, and the transport's own limit per message is part of transport fit.
• Transport fit becomes required, not optional: a protocol that sends a handle can only run over a transport that carries that kind. That's checked at build, against the transports declared (Transports), and a protocol using handles must declare one.
• Version comparison: changing a handle's kind is breaking.
• Languages: Rust and C map to the OS types. TypeScript has handles only in Node (file descriptors over Unix sockets, in limited cases) and in browsers (transferables over postMessage); its support claim says which.

Rights

A right restricts what the receiver can do with a handle: read but not write, map but not execute. It matters most for handing a sandboxed process a read-only view of a buffer or a file. Some systems attach rights to every handle (Zircon: read, write, map, duplicate; Mach: send and receive rights).

Open, to be settled after the rest of IPC:

Adding rights later tightens existing protocols, a breaking change, so it's best settled before 1.0. If rights come, R2 is the recommendation: read-only sharing is the real security need, and its small set works everywhere.

Who the peer is

The OS reports the peer: its process id, user and group (SO_PEERCRED on Linux), its audit token (macOS), its uid (Android Binder), its token (Windows). Unlike anything the peer sends, the peer can't forge it.

• Reported, not claimed: the transport puts the identity in the connection's state (Connections), and handlers and interceptors read it there.
• A guarantee, when declared: a protocol can require that a peer's identity is checked before any call is served. The check itself is an interceptor; what core guarantees is that the identity comes from the OS.

A peer that dies

A transport that reports a peer's exit closes the connection at once: every waiting call fails with "peer gone", instead of each waiting for its timeout.

Versions

Processes shipped together still skew: a partial update, an old helper process still running. The handshake stays, and IPC transports make it cheap: one message each way, on a connection that's often reused for the process's whole life.

Zero copy

A memory handle shares a region; reading a value in place in it needs a memory layout both sides agree on byte for byte. That's the exact-layout format in Comline for systems software.

Prior art

Open

• ~~Handles~~: decided, H2. The spellings (file, memory, channel, remote P, receiver P) are as proposed.
• Rights on handles: R1, R2 or R3 (above), settled later.
• Which platform IPCs get official profiles, and in what order.
• A shared-memory ring of Comline's own, and its side channel for peer death.
• Requiring a peer identity check: how a protocol states it.