Inter-Process Communication (IPC)

[!NOTE] This module explores the core principles of Inter-Process Communication (IPC), deriving solutions from first principles and hardware constraints to build world-class, production-ready expertise.

1. The Isolation Problem

Processes are isolated by design. Process A cannot access Process B’s memory. This prevents crashes and security breaches.

Imagine two people locked in separate, soundproof rooms. They cannot hear or see each other. This is exactly how the Operating System isolates processes via Virtual Memory to guarantee stability. If one person goes crazy and starts trashing their room (a crash), the other person is completely unaffected.

But sometimes, they need to collaborate on a task. How do they communicate through the walls? They need the Operating System to act as a secure messenger. This is the domain of Inter-Process Communication (IPC).

2. Mechanisms of IPC

1. Pipes (The Unix Way)

A unidirectional data channel. Imagine sliding a note under the door.

  • Anonymous Pipe: ls | grep txt. Used exclusively between related processes (parent and child). The OS buffers the data in a small, fixed-size queue in kernel memory.
  • Named Pipe (FIFO): A file on the filesystem that acts as a pipe. Any process with the right permissions can open it and communicate, even if they aren’t related.
  • Pros: Extremely simple, natural stream-oriented processing.
  • Cons: Unidirectional (you need two pipes for back-and-forth), unstructured byte-stream (you have to manually parse boundaries).

2. Sockets (The Network Way)

Bidirectional communication endpoints. Imagine establishing a dedicated telephone line between the rooms.

  • Unix Domain Sockets: Local file path. Extremely fast because it bypasses the network stack and communicates entirely in the kernel.
  • TCP/UDP Sockets: Network IP:Port. The universal standard for distributed apps, but works perfectly fine over localhost for local IPC.
  • Pros: The standard for networked and distributed microservices. Highly scalable.
  • Cons: Higher overhead due to the TCP/IP networking stack (even on localhost).

3. Shared Memory (The Fast Way)

The OS maps the same physical RAM pages into the virtual address spaces of both processes. Imagine knocking down a wall between the rooms and sharing a whiteboard.

  • Pros: Zero-copy IPC. Once mapped, the OS gets out of the way. It is phenomenally fast—the fastest form of IPC possible.
  • Cons: Race Conditions. What if both processes try to write to the whiteboard at the exact same millisecond? Data corruption occurs. You must use synchronization primitives like Mutexes or Semaphores.

4. Signals (The Minimal Way)

Tiny, asynchronous notifications sent by the OS to a process. Imagine an alarm bell ringing in the room. You don’t know what happened in detail, just that something happened.

  • SIGINT (Ctrl+C): Interrupt request.
  • SIGKILL (Kill -9): Die immediately. Cannot be intercepted.
  • SIGSEGV: Segmentation Fault (Invalid memory access).

3. Case Study: The Chromium Browser Architecture

Why does Chromium use thousands of processes instead of one big multithreaded process?

If a single browser tab crashes or executes malicious JavaScript, you don’t want it bringing down the entire browser or reading passwords from another tab.

  • Process Isolation: Every tab is a sandboxed process. The GPU renderer is a separate process. The network stack is a separate process.
  • The IPC Solution: Chromium uses highly optimized Named Pipes and Shared Memory.
  • When a WebGL game needs to draw to the screen, passing 10MB of pixel data through a pipe would require expensive memory copies. Instead, Chromium uses Shared Memory so the GPU process can read the pixels instantly. For tiny control messages (“User clicked button X”), it uses fast Unix Domain Sockets or pipes.

4. Interactive: The Pipe Plumber

Visualize how data flows through an OS pipe buffer. Pipes have limited capacity! If the pipe is full, the writer goes to sleep. If the pipe is empty, the reader goes to sleep.

Writer (Proc A)
Kernel Buffer (Max 8)
Reader (Proc B)
kernel> Pipe initialized. Buffer empty.

5. Code Implementations

Let’s look at how modern systems abstract IPC. We can contrast low-level C POSIX IPC with modern Go Channels.

C

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <sys/wait.h>

int main() {
  int pipefd[2];
  char buffer[100];

  // 1. Create the pipe (pipefd[0] is read, pipefd[1] is write)
  if (pipe(pipefd) == -1) {
    perror("pipe"); exit(1);
  }

  // 2. Fork into two processes
  pid_t pid = fork();

  if (pid == 0) {
    // CHILD PROCESS (Reader)
    close(pipefd[1]); // Close unused write end
    read(pipefd[0], buffer, sizeof(buffer));
    printf("Child received: %s\n", buffer);
    close(pipefd[0]);
  } else {
    // PARENT PROCESS (Writer)
    close(pipefd[0]); // Close unused read end
    char* msg = "Hello through the pipe!";
    write(pipefd[1], msg, strlen(msg) + 1);
    close(pipefd[1]);
    wait(NULL); // Wait for child to finish
  }

  return 0;
}

Go

package main

import (
  "fmt"
  "time"
)

func main() {
  // Go improves IPC by making "Communicating Sequential Processes" (CSP)
  // a first-class citizen. Channels are essentially typed, synchronized pipes.
  messages := make(chan string, 2) // Buffered: Max 2 capacity

  // Producer (Goroutine)
  go func() {
    fmt.Println("Writer: Sending 'ping'...")
    messages <- "ping"

    fmt.Println("Writer: Sending 'pong'...")
    messages <- "pong"

    fmt.Println("Writer: Buffer full. Next write will BLOCK...")
    messages <- "done"

    close(messages)
  }()

  time.Sleep(1 * time.Second)

  // Consumer (Main Thread)
  for msg := range messages {
    fmt.Println("Reader: Received", msg)
  }
}