Inter-process communication
Operating Systems · 10 interview questions
Processes are isolated by design, so exchanging data needs an explicit mechanism. The options trade speed against convenience.
Shared memory is the fastest, because after the initial mapping there is no kernel involvement at all — but the processes must synchronise access themselves. Message passing through pipes, FIFOs or message queues copies data through the kernel, which costs more but provides synchronisation and clean boundaries for free.
Sockets extend message passing across machines, which is why they dominate anything that might become distributed. Signals are not really a data channel: they carry a number and nothing more, and their handlers run asynchronously with severe restrictions on what is safe to call.
Inter-process communication interview questions
- Why is shared memory the fastest IPC mechanism?
- Because after the region is mapped, communication is ordinary memory access — no system calls and no copying through the kernel. The cost is that synchronisation is entirely the application's problem.
- What are the limits of an anonymous pipe?
- It's unidirectional and only usable between related processes, since the descriptors are inherited across fork. It's a byte stream with no message boundaries, and writing to one with no reader raises SIGPIPE.
- How does a named pipe differ from an anonymous one?
- A FIFO exists as a filesystem entry, so unrelated processes can open it by path. Otherwise it behaves like a pipe — a unidirectional byte stream.
- What does a message queue offer that a pipe doesn't?
- Discrete messages rather than a byte stream, so boundaries are preserved without framing. Messages can carry types or priorities and persist in the kernel until read, so sender and receiver needn't overlap in time.
- When would you choose sockets over other IPC?
- When the processes might not be on the same machine. Unix domain sockets are fast locally, and the same API extends across a network, so a design that may become distributed starts here.
- Why are signals a poor way to send data?
- A signal conveys only its number — there's no payload. Handlers run asynchronously, may interrupt anything, and are restricted to async-signal-safe functions, so they're for notification rather than communication.
- Why can't you call arbitrary functions in a signal handler?
- The handler may interrupt the same function mid-execution — if it interrupts malloc and then calls malloc, it can corrupt allocator state. Only async-signal-safe functions are permitted; the usual pattern is to set a flag and handle it in the main loop.
- What does memory-mapped I/O give you?
- A file mapped into the address space so it's read and written as memory, with the kernel paging blocks in on demand. It avoids explicit read/write calls and lets several processes share one mapping.
- What's the difference between blocking and non-blocking IPC?
- Blocking suspends the caller until the operation can proceed — simple but stalls the thread. Non-blocking returns immediately with a would-block indication, requiring polling or an event loop, which is how servers handle many connections at once.
- How would you choose between shared memory and message passing?
- Shared memory for high-volume data between processes on one machine, when you're willing to write the synchronisation. Message passing when you want isolation, natural synchronisation, or the option to move across machines later.
You'll forget most of this by next week
That's not a discipline problem, it's how memory works. In the app these come back on an expanding schedule — right before you'd lose them.
Start free for 7 days