📘 Processes and Threads

A process is a program in execution. A thread is a unit of execution inside a process. This page covers how the OS represents them, how it switches between them, how they are created, and how they talk to each other.

Table of Contents

1. Program vs Process
2. Process Memory Layout
3. The Process Control Block
4. Process States
5. Context Switching
6. Creating Processes: fork and exec
7. Zombies, Orphans, and Daemons
8. Threads
9. Threading Models
10. Green Threads, Coroutines, and Virtual Threads
11. Inter-Process Communication
12. Questions

1. Program vs Process

Running python twice gives two processes from one program, each with its own memory.

2. Process Memory Layout

Each process sees its own virtual address space.

High addresses
+---------------------------+
| Kernel space              |  mapped but inaccessible from user mode
+---------------------------+
| Stack                     |  grows down; locals, return addresses, one per thread
|            |              |
|            v              |
|                           |
| Memory-mapped region      |  shared libraries, mmap'd files, thread stacks
|                           |
|            ^              |
|            |              |
| Heap                      |  grows up; malloc / new
+---------------------------+
| BSS                       |  uninitialized globals (zeroed)
| Data                      |  initialized globals and statics
| Text (code)               |  read-only, executable, shareable
+---------------------------+
Low addresses

ASLR (address space layout randomization) places these at random offsets each run to make exploits harder.

See it live: cat /proc/<pid>/maps on Linux or vmmap <pid> on macOS.

3. The Process Control Block

The kernel tracks each process in a PCB (on Linux, struct task_struct).

On Linux, threads are also task_structs that share the memory map and file table; the kernel schedules tasks, not processes.

4. Process States

Load average on Linux counts tasks in R and D, so a high load with idle CPUs often means processes stuck on I/O.

5. Context Switching

A context switch saves the state of the running task and restores another.

1. Timer interrupt or blocking system call enters the kernel.
2. Save registers, program counter, and stack pointer into the current task's PCB.
3. Scheduler picks the next task.
4. If it belongs to a different process, switch the page table (update CR3 on x86).
5. Restore the next task's registers and return to user mode.

Too many switches (thousands of threads, heavy lock contention) waste CPU; check vmstat 1 (cs column) or pidstat -w.

Mode switch vs context switch: a system call switches user to kernel mode in the same task; a context switch changes which task runs.

6. Creating Processes: fork and exec

Unix separates creation into two steps.

pid_t pid = fork();              // duplicate the calling process
if (pid == 0) {
    // child: replace the program image
    execlp("ls", "ls", "-l", NULL);
    perror("exec failed");       // only reached if exec fails
    _exit(1);
} else if (pid > 0) {
    int status;
    waitpid(pid, &status, 0);    // parent waits and reaps the child
} else {
    perror("fork failed");
}

Copy-on-write: fork does not copy memory. Parent and child share pages marked read-only; a page is copied only when one of them writes to it. This makes fork fast, and is why Redis can snapshot a large dataset with fork (only pages modified during the snapshot get copied).

Classic puzzle:

fork(); fork(); fork();
printf("hi\n");   // prints 8 times: 2^3 processes

Why split fork and exec? The child can adjust its environment between the two (redirect file descriptors, change directory, drop privileges), which is exactly how a shell implements ls > out.txt.

7. Zombies, Orphans, and Daemons

Zombies use no memory or CPU, but each holds a PID; enough of them can exhaust the PID limit. In containers, your app often runs as PID 1 and must reap zombies itself, which is why tiny init processes like tini (or docker run --init) exist.

8. Threads

A thread has its own stack, registers, and program counter, and shares everything else with other threads in the process.

Chrome uses processes per site for security and crash isolation; a database like PostgreSQL uses a process per connection, while MySQL uses a thread per connection.

Why use threads:

• Use multiple cores for CPU-bound work.
• Keep a UI or server responsive while one thread blocks on I/O.
• Share large in-memory data without copying.

Amdahl's law: if a fraction p of work can be parallelized, the max speedup on n cores is 1 / ((1 - p) + p / n). With 90 percent parallel code, even infinite cores cap at 10x.

9. Threading Models

Linux pthreads, Windows threads, and Java platform threads use one-to-one. Go goroutines, Java virtual threads, and Erlang processes use M:N inside their runtimes.

10. Green Threads, Coroutines, and Virtual Threads

Go goroutines start with a small stack (a few KB) that grows as needed, and the Go scheduler multiplexes them across OS threads (GOMAXPROCS), so millions of goroutines are practical.

Java virtual threads (Java 21) let blocking-style code scale like async code: a virtual thread unmounts from its carrier platform thread when it blocks on I/O. Java 24 removed the main pinning problem with synchronized blocks.

Event loops (Node.js, nginx, Redis) use a single thread plus non-blocking I/O instead of many threads; see I/O and Linux Internals.

11. Inter-Process Communication

Processes are isolated by design, so the OS provides explicit channels.

Message passing is simpler and safer; shared memory is faster but you must synchronize.

Signals

Graceful shutdown pattern: handle SIGTERM, stop accepting new work, finish in-flight work within a deadline, exit. Kubernetes waits terminationGracePeriodSeconds (30 by default) before sending SIGKILL.

Signal handlers run asynchronously and may interrupt anything, so only async-signal-safe functions may be called in them (not malloc or printf); the usual trick is to set a flag or write to a self-pipe.

12. Questions

Next: CPU Scheduling.