Learning Question
How do separate processes communicate if they cannot directly enter each other’s private memory?
Processes are isolated by default.
One process cannot simply call a function inside another process or freely read its private memory.
Interprocess communication, or IPC, uses OS-managed mechanisms to move data or coordinate behavior across process boundaries.
The first mental model is:
IPC is communication through an operating-system-managed boundary, not direct execution inside another process.
Why IPC Is Needed
Process isolation is useful because it protects programs from each other.
But useful systems often need processes to cooperate.
Examples include:
- a shell sending output from one command into another
- a browser process talking to a renderer process
- a server process accepting client connections
- a supervisor controlling worker processes
- programs sharing results through files or shared memory
IPC gives programs controlled ways to communicate without removing the process boundary.
Pipes
A pipe is a unidirectional byte stream managed by the operating system.
One end is used for writing.
The other end is used for reading.
Shell pipelines use pipes to connect processes.
For example:
producer | consumerThe producer writes to standard output.
The consumer reads from standard input.
The shell sets up the descriptors so the bytes flow through a pipe instead of directly to or from the terminal.
The two programs do not call each other’s functions.
They exchange bytes through the kernel.
Pipe Blocking Behavior
Pipes have finite kernel-managed buffers.
If a process reads from an empty pipe while a writer is still open, it may block.
If a process writes to a full pipe, it may block until the reader consumes data.
If all writing ends are closed, a reader can observe end of file.
If all reading ends are closed, a writer may receive an error or signal.
These behaviors come from OS-managed pipe state, not from either program knowing the other’s implementation.
Sockets
Sockets are communication endpoints.
They can be used for communication on the same machine or across a network, depending on socket type and address family.
Like pipes, sockets can be represented by file descriptors on Unix/Linux.
Unlike simple pipes, sockets can support bidirectional communication and network protocols.
A socket is still an OS-managed communication endpoint.
The process uses descriptors and system calls.
The kernel manages buffers, protocol state, blocking, and delivery.
Shared Memory
Some IPC mechanisms intentionally allow multiple processes to map the same memory region.
Shared memory can be faster than copying data through pipes or sockets, but it also requires synchronization.
If two processes can write the same memory, they need rules for ownership, ordering, and visibility.
Shared memory weakens the default private-memory boundary in a controlled way.
It does not remove the need for OS-managed setup and permissions.
Files as IPC
Processes can also communicate through files.
One process writes data.
Another process reads it.
This is simple and durable, but it has different timing and coordination properties from pipes, sockets, or shared memory.
The file system becomes the shared medium.
Locks, atomic rename patterns, or other coordination mechanisms may be needed to prevent inconsistent reads and writes.
Core Mental Model
Processes communicate through explicit channels because private process memory is isolated.
When reasoning about IPC, ask:
What OS-managed object connects the processes, what data or events pass through it, and what blocking or synchronization rules apply?
Final Summary
Pipes, sockets, shared memory, files, and related IPC mechanisms let separate processes cooperate without directly entering each other’s private execution state.
The operating system owns the communication boundary and provides the handles, buffers, permissions, and wakeups that make the exchange possible.