Compare the main inter-process communication mechanisms — pipes, shared memory, sockets and signals — and explain how you would choose among them for moving a high volume of data between two processes on the same machine.

## Why IPC exists at all Processes have isolated address spaces, so the cheap sharing threads enjoy is unavailable by construction. Every mechanism below is a way to punch a controlled hole through that isolation, and each one trades a different amount of the isolation away. ## Pipes A pipe is a kernel-managed byte buffer with a write end and a read end. Writers append, readers consume in order. When the buffer fills, the writer blocks; when it empties, the reader blocks. That blocking is free **backpressure**: a fast producer is automatically throttled by a slow consumer. Properties worth naming: unidirectional (two are needed for a dialogue), no message boundaries (the reader may get a partial or a merged write, so you must frame data yourself with lengths or delimiters), and typically inherited across process creation, which is what makes shell pipelines work. Each byte crosses the user/kernel boundary twice. ## Sockets Sockets generalize the pipe idea into a named, connection-oriented (or datagram) channel. Two important variants: - **Local/domain sockets** stay inside one machine, skipping checksums, routing and the network stack, but keep the socket programming model. - **Network sockets** carry the same API across hosts. Compared to pipes, sockets are bidirectional, addressable by name rather than by inheritance, and datagram forms preserve message boundaries. The strategic advantage is **location transparency**: a design that already talks over sockets can be split across machines without changing its communication model. The cost is protocol overhead and still one copy in each direction. ## Shared memory Both processes map the same physical pages into their address spaces. After setup, a write by one is visible to the other with **no kernel involvement and no copy** — the only mechanism that reaches memory bandwidth rather than syscall-plus-copy speed. Everything that makes it fast makes it dangerous: - There is no framing, no flow control and no ordering guarantee. You build a protocol yourself, typically a ring buffer with producer and consumer indices. - Both sides now share mutable state, so you need cross-process synchronization (shared mutexes/semaphores, or lock-free index manipulation with the appropriate memory ordering). - A crash mid-update leaves the shared region in a state the survivor must be able to recognize and recover from — a corrupted shared region can take down both parties, so the isolation benefit is partly given back. - Notification usually needs a companion channel: shared memory tells you *what*, a pipe, socket or semaphore tells you *when*, so the reader does not have to spin. ## Signals A signal is an asynchronous notification delivered to a process: a small identifier and nothing meaningful beyond it. Handlers run at arbitrary points in the target's execution, which severely restricts what they may safely do — the standard discipline is to record a flag or write one byte to a pipe and let the normal loop do the real work. Signals are for **control-plane events**: terminate, reload configuration, child exited, resize. Using them to carry data is a design error; they can coalesce, they carry no payload, and their delivery timing is not yours to control. ## Other mechanisms worth naming Message queues give named, boundary-preserving, kernel-buffered messages with optional priority; memory-mapped files behave like shared memory with a durable backing store and are a common way to share large read-mostly datasets; and the family of event/notification objects exists precisely to pair with shared memory for the wake-up problem. ## Choosing for a high-volume local transfer Walk the decision explicitly: 1. **What is the data rate, really?** Copying is fast. If you are moving tens of megabytes a second, a pipe or local socket will not be your bottleneck and simplicity wins. 2. **What shape is the data?** Streaming and framed messages fit pipes and sockets naturally. Large fixed-size buffers — video frames, captured pages, tensors — fit shared memory, because the copy is exactly the cost you are trying to remove. 3. **Do you need flow control?** Pipes and stream sockets give it for free. A shared-memory ring buffer requires you to design it, and to decide what a full buffer means: block, drop, or overwrite. 4. **What happens when one side dies?** Pipes and sockets deliver a clean end-of-stream or error. Shared memory can leave a half-written structure, so you need versioned or index-based protocols that a survivor can validate. 5. **Might these processes end up on different machines?** If yes, choose sockets now; that is the only option that survives the move unchanged. A defensible senior answer is a staged one: start with a local socket or pipe, instrument, and adopt a shared-memory ring — with a small pipe or semaphore as its wake-up channel — only when profiling shows copy and syscall cost dominating. Adding shared memory converts a copy problem into a concurrency problem, and that trade should be paid for with evidence.