IPC: Deliberate Holes in Process Isolation

A process cannot read another process’s memory, cannot see its descriptors and cannot call its functions. That is not a limitation the kernel apologises for — it is the property that lets a crashed renderer take down one browser tab instead of the browser, and lets a leaking worker be killed and restarted without touching its siblings (Program versus Process, Why Virtual Memory?). The cost is that any cooperation between processes has to go through the kernel, or through a region the kernel has explicitly agreed to map into both.

So every IPC mechanism is an answer to the same question with a different emphasis. How much isolation are you willing to give back? How many copies are you willing to pay for? Does the other side have to be on this machine? Do you need the kernel to preserve message boundaries and order, or is a byte stream enough? Do you need to *notify* the other side, or move *data* to it?

The five mechanisms below are what Unix-style systems give you; Windows has counterparts (anonymous and named pipes, file mappings, Winsock, mailslots, console control events) with different names and some different semantics. Where the lesson says “on Linux” it means it.

Start with the simplest thing the kernel can do: keep a small buffer and let one process write into it while another reads from it. That is a pipe (Pipes: A Kernel Buffer Between Two Processes): one direction, byte stream, kernel-mediated, two copies (user → kernel → user), local only, and the kernel blocks whichever side gets ahead. It is the shell’s |.

Remove the copies: map the *same physical pages* into both address spaces. That is shared memory (Shared Memory: Zero Copies, Zero Protection): zero copies, the fastest IPC there is, and no help whatsoever from the kernel about who writes when — synchronisation is now your problem. Give the pipe framing and two directions and let the far end be on another machine: that is a socket (The Socket: A Descriptor With Two Kernel Buffers Behind It) — a Unix domain socket when both ends are local, TCP or UDP when they are not. Give the pipe *message* semantics — discrete messages, priorities, persistence across process exit — and you have a message queue (POSIX mq_open, or System V). Finally, drop the data entirely and just poke the other process: a signal (Signals: Asynchronous Notifications From the Kernel) — a number delivered asynchronously, interrupting whatever the target was doing.

Notice what varies: how many times the bytes are copied, whether the kernel arbitrates access, whether message boundaries survive, and whether the peer can be remote. Those are the columns of the comparison.

Speed here means the cost of moving one message between two processes on the same machine, not throughput of a tuned system. Shared memory wins because there is nothing to move; a pipe or Unix socket costs two copies and two system calls per message (roughly 1–5 µs round trip on a modern Linux box, dominated by the context switches, not the copying); a TCP loopback connection adds the transport stack on top — still microseconds, but more of them. Isolation is the inverse: the mechanisms that copy through the kernel keep the two processes unable to corrupt each other; shared memory gives that up.

Framing is the property people forget until it bites: a pipe and a stream socket deliver a byte stream, so two write() calls of 100 bytes may arrive as one read() of 200 or three reads of 70/70/60. Message queues and datagram sockets preserve boundaries. Ordering is guaranteed by everything except UDP, which guarantees nothing — and by shared memory only if you build it.

Most application code never chooses: the runtime does. subprocess.run(capture_output=True) and child_process.spawn use pipes. Every database client library uses a socket — a Unix domain socket when the server is local (PostgreSQL’s /var/run/postgresql/.s.PGSQL.5432), TCP otherwise. Docker’s CLI talks to the daemon over /var/run/docker.sock, a Unix socket, which is why mounting that file into a container hands the container the host. Browsers use sockets or pipes for control messages and shared memory for pixels, because a 4K frame is 33 MB and copying it sixty times a second would be absurd.

When you do choose, the questions are the columns of the table. Need to send a 2 GB buffer to a sibling process every few milliseconds? Shared memory plus a small control channel. Need the peer to possibly be on another machine next year? A socket, today, so the protocol does not have to change. Need to tell a process to reload its config? A signal (SIGHUP by convention) — nginx, PostgreSQL and sshd all do this. Need work items to survive the consumer crashing? Not an OS message queue: a broker such as RabbitMQ or Kafka, which is a *socket* protocol to a *process* that owns durability — the Software Architecture idea of a message queue is built on top of the OS’s socket, not the OS’s mq_open.