Processes

Program vs. Process
What a Process Contains
Process IDs
Each Process Gets Its Own Memory
Sharing the CPU: The Scheduler
Parent and Child Processes
How a Process Ends
Background Processes
Try It Yourself

1. Program vs. Process

These two words sound interchangeable, but they mean different things:

A program is a file on disk containing instructions — like chrome.exe, or /Applications/Telegram.app. It just sits there. It isn't doing anything.
A process is a program that's running: it has been loaded into RAM, and the CPU is executing its instructions.

A recipe book on a shelf is a program. Someone actually cooking from it, with ingredients on the counter and the oven on, is a process.

One program can have many processes at once. Open three separate Terminal windows and you have three processes of the same program. Chrome goes further: it deliberately runs a separate process for each tab and extension, so one misbehaving website can't crash the whole browser.

2. What a Process Contains

When the OS starts a process, it sets up everything the program needs to run:

Code — the program's instructions, copied from disk into RAM
Memory — space for the program's data, including:
- the stack, which tracks which function is running and holds its local variables
- the heap, for data created while the program runs (objects, arrays, strings)
CPU state — the values in the registers and the program counter (the bookmark from chapter 3)
Open resources — files it has opened, network connections, and so on
Identity — which user started it, which determines what it's allowed to do

The OS keeps track of all of this in a record for each process, so it can pause the process and resume it later exactly where it left off.

3. Process IDs

Every process gets a unique number called a PID (Process ID). The OS uses the PID to refer to the process — for example, to stop it or check how much memory it's using.

PIDs are assigned when a process starts and are released when it ends. If you open and close an app several times, it will usually get a different PID each time.

You'll see PIDs constantly as a developer: in Task Manager, in error messages, and when a command like kill 4821 stops a specific process.

4. Each Process Gets Its Own Memory

This is one of the most important ideas in the whole series.

Every process believes it has the whole computer's memory to itself. Each one sees its own private range of addresses, starting from zero. This is called virtual memory. Behind the scenes, the OS and the CPU translate each process's addresses to real locations in physical RAM — different locations for each process.

Two processes can both use "address 1000" and never collide, because each one's address 1000 points to a different real location.

This gives us:

Isolation — a process can't read or overwrite another process's memory. Your browser can't peek at your password manager's memory.
Stability — when one process crashes, the others are unaffected.
Flexibility — the OS can move memory around, or out to swap (chapter 4), without the program noticing.

If a program does try to access memory that doesn't belong to it, the CPU raises an error and the OS ends the process. On Linux and macOS this is the famous segmentation fault ("segfault").

The downside of isolation is that processes can't simply share variables. To cooperate, they have to communicate on purpose — through files, network connections, or special OS features for inter-process communication.

A laptop might have 8 cores, but hundreds of processes. How do they all run?

The part of the kernel called the scheduler gives each process a turn. A process runs on a core for a tiny slice of time — a few milliseconds — and then the scheduler pauses it, saves its CPU state, and lets another process run. This swap is called a context switch.

It happens so fast — many thousands of times a second — that every program seems to be running continuously. It's like a single teacher answering questions from a whole classroom by moving from student to student very quickly.

At any moment, a process is in one of a few states:

Running — currently on a CPU core
Ready — able to run, waiting for its turn
Waiting (or blocked) — can't continue until something happens, like a file finishing loading or a network reply arriving

Most processes on your computer spend almost all of their time waiting. A chat app does nothing until a message arrives. This is why your CPU usage is often only a few percent even with dozens of apps open.

6. Parent and Child Processes

Processes are started by other processes. When you double-click an app, the desktop process asks the OS to start it. When you type a command in a terminal, the terminal's shell starts it.

The process that starts another is the parent; the new one is the child. So all the processes on a computer form a family tree, going all the way back to the first process the kernel started during boot (chapter 6).

As a developer you'll meet this constantly: running npm run dev starts a process, which starts Node.js, which may start more child processes of its own.

7. How a Process Ends

A process can end in a few ways:

It finishes normally — the program reaches its end and exits.
It crashes — it does something illegal (like a segfault) or hits an error nobody handled, and the OS ends it.
It's told to stop — by you, another program, or the OS.

When a process exits, it reports an exit code — a number that tells its parent how things went:

0 means success
anything else means some kind of failure — the program chooses what each number means

Exit codes matter more than you'd think: CI/CD pipelines, Docker, and scripts all check them to decide whether a step passed or failed.

When you stop a process yourself, the OS sends it a signal — a short message. The two you'll use most (on Linux and macOS):

SIGTERM — "please stop". The program gets a chance to clean up — save data, close connections — before exiting. This is what closing an app normally does.
SIGKILL — "stop now". The OS ends the process immediately; it can't refuse or clean up. This is the Force Quit / End task option, for when an app is frozen.

When a process ends — however it ends — the OS takes back all its RAM, closes its files, and frees its PID.

8. Background Processes

Many processes have no window at all. They run quietly in the background, doing jobs like:

checking for updates
syncing files to the cloud
indexing your files for search
running a database or web server

These are called services on Windows and daemons on Linux and macOS (a daemon's name often ends with d, like sshd or dockerd).

When you deploy a backend app to a server, it runs as exactly this: a long-running background process with no window, listening for requests.

9. Try It Yourself

Open your process viewer:

Windows: Task Manager (Ctrl + Shift + Esc) → Details tab
macOS: Activity Monitor → CPU tab
Linux: run top, or ps aux for a snapshot

Then:

Find the PID column. (On Windows it's shown on the Details tab; in Activity Monitor it's called PID.) How many processes are running in total?
Find one program with many processes. Search for your browser — Chrome, Edge, or Safari. Open a few more tabs and watch new processes appear.
See the scheduler at work. Sort by CPU. Most processes are at 0% because they're waiting.
End a process. Open a simple app like Calculator, find it in the list, select it, and click End task (Windows) or the ✕ button → Quit (macOS). Watch it disappear from both the list and your screen. Try Force Quit too, and notice the app gets no chance to ask "Save changes?".

A process is a running program with its own memory. But what if one program needs to do several things at once? That's what threads are for.