← Interview Prep
Linux Kernel — Process Communication (IPC)
How processes exchange data and coordinate: pipes/FIFOs, Unix-domain sockets (fd passing), shared memory (fastest, you own the locking), message queues, semaphores, signals and eventfd; System V vs POSIX APIs, the futex, and choosing the right mechanism.
How separate processes — isolated by design — exchange data and coordinate. There are several mechanisms; the
interview skill is picking the right one and knowing its trade-offs. Original, interview-focused notes.
Two questions decide the mechanism: do you need to move a stream of bytes, share a
region of memory, or just signal/synchronize? And do the processes share a parent, a
machine, or neither?
The mechanisms
| Mechanism | Shape | Notes |
|---|
| Pipe | Unidirectional byte stream | Between related processes (shell |). Anonymous; kernel-buffered; blocks when full/empty. |
| FIFO (named pipe) | Byte stream via a filesystem name | Lets unrelated processes connect (mkfifo). |
| Unix-domain socket | Stream or datagram, bidirectional | Local sockets; can pass fds and credentials (SCM_RIGHTS) — the modern, flexible choice. |
| Shared memory | A shared memory region | Fastest — no copy through the kernel; but you must synchronize access. |
| Message queue | Discrete messages, prioritized | Message boundaries preserved (unlike a byte stream). |
| Semaphore | Counter for synchronization | Guards access to a shared resource (often paired with shared memory). |
| Signal | A single async notification | Minimal data; see Signals. |
| eventfd / pipe self-notify | A wakeup fd | Integrates cleanly with epoll event loops. |
Shared memory — fastest, but you own the locking
- Processes map the same physical pages, so a write by one is instantly visible to the other — zero
copies, the reason it's the fastest IPC.
- The kernel gives you the memory, not the coordination: you need a semaphore, a
futex-based lock, or atomics to prevent races — and to publish data safely you need memory
ordering, just like in-kernel synchronization.
- Two APIs: legacy System V (
shmget/shmat, IPC keys) and the cleaner
POSIX (shm_open + mmap, named like /myshm). Plain
mmap(MAP_SHARED) of a file/anon region is the same idea.
SysV vs POSIX
- Both provide shared memory, message queues, and semaphores. System V uses numeric
IPC keys and persists until removed (
ipcs/ipcrm) — objects leak if you
forget. POSIX uses names and fds, integrates with the filesystem and
mmap, and is generally preferred in new code.
- futex ("fast userspace mutex") is the primitive under pthread mutexes/condvars: it stays in
userspace on the uncontended path and only makes a syscall to sleep/wake when there's contention — cheap locking
that also works across processes on shared memory.
Choosing
- A stream between processes → pipe (related) / FIFO / Unix socket (unrelated, or need
bidirectional/fd-passing).
- Bulk, high-throughput, low-latency → shared memory + a lock (databases, ring buffers, trading).
- Discrete jobs/messages → message queue.
- Just "wake up" / coordinate → signal, eventfd, or a semaphore.
- Across machines → none of the above; use network sockets.
Likely interview questions
- List the IPC mechanisms and when you'd pick each.
- Why is shared memory the fastest, and what does the kernel not give you? (no copy; no synchronization)
- Pipe vs FIFO vs Unix socket — related processes, names, bidirectional/fd-passing?
- Message queue vs pipe — what does it preserve? (message boundaries)
- System V vs POSIX IPC — keys/persistence vs names/fds, and which leaks if forgotten?
- What is a futex, and why is it "fast"? (userspace fast path, syscall only on contention)
- How do you notify an epoll loop from another thread/process? (eventfd/self-pipe)
- Which IPC works across machines? (network sockets — the local ones don't)