Processes: Programs Come Alive

Processes: Programs Come Alive

A musical score is just ink on paper. When an orchestra performs it, it comes alive — there is sound, rhythm, memory, and progression through time. A program is the static file sitting on your disk. A process is that score being performed: dynamic, consuming resources, changing state moment by moment.

The same score can be performed by two orchestras simultaneously without interference. Likewise, you can open two Chrome windows at once — both stem from the same executable file, yet they run as completely independent processes. If you think in object-oriented terms: a program is the class, a process is an instance. One class, many possible instances.

Core Concepts

ELF: What a Program Actually Looks Like

On Linux, executable programs use the ELF (Executable and Linkable Format) file format. You can verify this instantly:

$ file /bin/ls
/bin/ls: ELF 64-bit LSB pie executable, x86-64, ...

Inside every ELF file are several named sections. The three most important:

ELF File Layout
┌──────────────────────────────┐
│  ELF Header (magic + arch)   │
├──────────────────────────────┤
│  .text section               │
│  Machine instructions (R/O)  │
│  This is where your code is  │
├──────────────────────────────┤
│  .data section               │
│  Initialized global vars     │
│  e.g.: int x = 42;           │
├──────────────────────────────┤
│  .bss section                │
│  Uninitialized global vars   │
│  e.g.: int y;                │
│  (zero bytes on disk!)        │
├──────────────────────────────┤
│  Other sections (symtab...)  │
└──────────────────────────────┘

The .bss name comes from a 1950s assembler directive — "Block Started by Symbol" — and has stuck ever since. It takes up almost no disk space: the file just records "I need X bytes of zeroed memory here." When the OS loads the program, it allocates and zeroes that region on demand.

Process Address Space: From 0 to Max

When a program is loaded, the OS creates an isolated virtual address space for it. On 64-bit Linux the layout looks like this (low addresses at the bottom):

High address
┌──────────────────────────────┐ 0xFFFFFFFFFFFFFFFF
│   Kernel space (invisible)   │
├──────────────────────────────┤ 0x7FFFFFFFFFFFFFFF
│   Stack                      │  ← grows downward
│   Function call frames       │
│   Local variables            │
│   ...                        │
│   ↓                          │
│                              │
│   ↑                          │
│   Heap                       │  ← grows upward
│   malloc / new allocations   │
├──────────────────────────────┤
│   .bss (zeroed globals)      │
├──────────────────────────────┤
│   .data (initialized globals)│
├──────────────────────────────┤
│   .text (code)               │
├──────────────────────────────┤
Low address  ~0x0000000000400000

Stack and heap grow toward each other with a large gap between them. If you malloc endlessly without freeing, or recurse too deeply, they collide — producing the Out of Memory or Stack Overflow errors you have almost certainly encountered.

Creating Processes: fork and exec

Linux creates new processes with the classic fork + exec two-step:

Parent process (shell)
    │
    │  fork()
    │─────────────────────────────►  Child (exact copy of parent)
    │                                    │
    │                                    │  exec("ls", ...)
    │                                    │  Replace self with new program
    │                                    │
    │  wait()                            │  ls starts executing
    │◄────────────────────────────────── │  ls finishes, exit()
    │
  shell resumes

fork() creates a copy-on-write snapshot of the parent — no actual memory is copied until the child tries to write something, at which point only that one page is duplicated. exec() then replaces the entire address space with the new program's image and jumps to its entry point.

The Process State Machine

Every process passes through five states during its lifetime:

          fork()
            │
            ▼
        ┌───────┐
        │  New   │
        └───┬───┘
            │  Enters ready queue
            ▼
        ┌───────┐   CPU frees up
        │ Ready  │◄──────────────────┐
        └───┬───┘                   │
            │ Scheduler picks it     │
            ▼                       │
        ┌───────┐   Time slice ends  │
        │Running│───────────────────┘
        └───┬───┘
        │       │
 wait   │       │ exit()
 for I/O▼       ▼
    ┌───────┐ ┌───────────┐
    │Blocked│ │ Terminated│
    └───┬───┘ └───────────┘
        │ I/O completes
        └──────► Ready

"Blocked" does not mean the process is crashed. It simply means it's waiting for something — a disk read to finish, a network packet to arrive, keyboard input. Once that event occurs, the OS moves it back to the ready queue.

PCB: The Process's Identity Card

The OS tracks every process using a data structure called the PCB (Process Control Block). It contains:

• PID (process ID)
• Current state (ready / running / blocked)
• CPU register snapshot (saved when the process is switched out)
• Memory map (page table pointer)
• List of open file descriptors
• Signal handlers
• Parent PID and child process list

In the Linux kernel the PCB is the task_struct defined in include/linux/sched.h. It has hundreds of fields — everything the kernel needs to know about a process is in there.

Hands-On Verification

# View the process tree with PIDs
pstree -p

# See the address space of the current shell
cat /proc/$$/maps

# Inspect ELF sections of a binary
readelf -S /bin/ls | grep -E "\.text|\.data|\.bss"

# Quick size summary of each section
size /bin/ls
# Output:
#    text    data     bss     dec     hex filename
#  143416    4824    4664  152904   25548 /bin/ls

# Demonstrate fork in Python
python3 -c "
import os
pid = os.fork()
if pid == 0:
    print(f'Child: PID={os.getpid()}, parent={os.getppid()}')
    os._exit(0)
else:
    print(f'Parent: PID={os.getpid()}, child={pid}')
    os.wait()
"

🔬 Going Deeper

How Clever Is Copy-on-Write?

If fork() actually duplicated all 500 MB of a parent's memory, the operation would take hundreds of milliseconds — completely unacceptable for a shell spawning commands every second. Copy-on-Write solves this: after fork(), parent and child share every memory page, all marked read-only. The moment either side tries to write to a page, the CPU raises a page fault, the kernel copies just that one page, and execution continues. In the extremely common fork() + exec() pattern (spawning a new program), the child never writes to the old pages at all — they get discarded immediately when exec() replaces the address space.

Process Isolation Is the Foundation of Security

Every process lives in its own virtual address space, enforced by the CPU's page tables. Process A's virtual address 0x401000 and Process B's virtual address 0x401000 map to completely different physical pages. The OS can also intentionally map the same physical page into multiple processes — this is how shared memory (via mmap or shmget) works, enabling high-speed inter-process communication without copying.

Recommended Reading:

• Computer Systems: A Programmer's Perspective (CSAPP) — Chapter 8, Exceptional Control Flow. The fork/exec/wait trio is explained more precisely here than anywhere else.
• Operating Systems: Three Easy Pieces (OSTEP) — Part II, Virtualization. Address spaces, paging, and the TLB are all covered in a logical sequence that builds one concept cleanly on top of the last.
• Linux kernel source kernel/fork.c — The copy_process() function is the real implementation of fork(). Reading it alongside OSTEP's paging chapters is a genuinely rewarding experience.