Processes in Execution

From Icon to Running Entity

When you double-click the Chrome icon on your desktop, something fundamental happens. Before you clicked, Chrome was just a program — a passive collection of machine code sitting inert on your SSD, taking up a few hundred megabytes of disk space, doing absolutely nothing.

The moment you clicked, the OS transformed that passive code into an active process: it loaded the executable into RAM, set aside a private memory region, created a stack for function calls, handed it a chunk of CPU time, and began tracking it with a data structure called the Process Control Block. Now Chrome is alive — it is responding to your keyboard, fetching web pages, playing video, and doing so without interfering with Spotify, VSCode, or the fifty other processes running alongside it.

The OS is the entity that manages every one of those living processes simultaneously. Understanding how it does that is the foundation of everything else in OS theory.

Program vs. Process

You can run the same program multiple times — each run is a separate, independent process with its own memory and state.

Process Memory Layout

Every process gets its own private virtual address space. The OS divides that space into four logical segments:

• Text — the compiled instructions; marked read-only to prevent self-modification
• Data — global and static variables your code declared
• Heap — memory you request at runtime (malloc in C, new in C++, all Python objects)
• Stack — automatically managed call frames; each function call pushes a frame, each return pops it

The Process Control Block (PCB)

The OS needs to track everything about a process so it can pause it, resume it, and manage its resources. All of that information lives in the Process Control Block — a data structure in kernel memory, one per process.

On Linux, the PCB is called task_struct and is defined in include/linux/sched.h. It is one of the largest and most important data structures in the Linux kernel — containing over 300 fields.

Process States

A process does not run continuously. It cycles through several states depending on whether it has CPU, is waiting for I/O, or is brand new.

The Five-State Model

Only one process per CPU core can be in the Running state at any moment. A quad-core CPU can run exactly four processes simultaneously.

Process Creation with fork()

On Unix/Linux, every process (except the initial init/systemd process, PID 1) is created by another process calling fork().

fork() creates an exact copy of the calling process — the child gets a duplicate of the parent's memory, open file descriptors, and registers. The only difference: fork() returns the child's PID to the parent, and returns 0 to the child.

#include <unistd.h>

pid_t pid = fork();

if (pid == 0) {
    // This code runs in the CHILD process
    printf("I am the child, PID = %d\n", getpid());
} else {
    // This code runs in the PARENT process
    printf("I created child PID = %d\n", pid);
}

After fork(), the child typically calls exec() to replace its memory with a new program — this fork-exec pattern is how your shell launches every command you type.

Copy-on-Write (CoW): Modern kernels don't actually copy memory immediately on fork(). Pages are shared and only duplicated when either process tries to write to them — a major performance optimization.

Process Termination

Processes end in three ways:

1. Normal exit — program calls exit(0) or returns from main()
2. Error exit — unhandled exception, segfault, divide-by-zero triggers a signal
3. Killed — another process (or the OS) sends a termination signal (SIGKILL, SIGTERM)

When a process exits, the OS reclaims its memory, closes its file descriptors, and removes its PCB — but only after the parent calls wait() to collect the exit status. Until then, the dead process becomes a zombie — its PCB still exists in kernel memory to hold the exit code.

Inspecting Processes in Linux

# Show all running processes with details
ps aux

# PID   USER     %CPU  %MEM   COMMAND
# 1     root      0.0   0.0   /sbin/init
# 842   www-data  0.1   1.2   nginx: worker
# 4821  alice     12.3  4.5   /usr/bin/python3 train.py

# Real-time process monitor (like Task Manager)
top

# More readable alternative to top
htop

# Show process tree (parent-child relationships)
pstree

# Show all processes for current user
ps -u $USER

The %CPU column in ps aux shows the percentage of CPU time the process has used since it started — not instantaneous usage (that is what top shows, updated every second).

Process vs. Thread (Preview)

A process is a heavyweight entity — creating it, switching between processes (context switching), and destroying it all take significant time because the OS must save and restore the entire PCB and memory mapping.

Threads solve this by allowing multiple execution flows within the same process, sharing the same memory space. We will explore threads in depth in the next lesson.

Real-World Perspective

• On Linux, PID 1 is systemd — every process on the system is a descendant of it.
• On macOS, open Activity Monitor and look at the process tree — you will see launchd (PID 1) as the root of everything.
• On Windows, open Task Manager → Details tab to see PIDs. The Process Explorer tool from Sysinternals shows the parent-child relationship as a tree.
• The Linux kernel scheduler keeps the run queue (ready processes) and wait queue (blocked processes) as linked lists of task_struct pointers.

Key Takeaways

• A program is static code on disk; a process is that code actively running in memory with its own resources.
• Each process has a private virtual address space divided into text, data, heap, and stack segments.
• The PCB is the kernel's record of everything about a process — state, registers, memory maps, open files.
• Processes transition through five states: New → Ready → Running → Waiting → Terminated.
• fork() creates new processes on Unix; the child then typically calls exec() to run a different program.
• ps aux and top are your primary Linux tools for inspecting running processes.