Putting it together: what happens when you run a program

Every concept from this domain shows up in the few hundred milliseconds between typing a command and seeing output — this lesson walks that whole sequence once, end to end, tying the pieces together instead of leaving them separate.

Intermediate

3 min read

The walkthrough: running `python script.py`

Following one ordinary command from keystroke to output touches nearly every idea covered in this domain — this lesson is a deliberate synthesis, not new material.

Step by step

The shell reads your command and, to actually run it, asks the kernel to create a new process via the fork() system call (lesson 1) — this duplicates the shell's own process as a starting point.
exec() replaces that new process's memory with the target program's actual code, setting up its virtual address space: code, data, heap, and stack regions (lesson 3), all backed by virtual memory the MMU will translate on every access (lesson 6).
The process enters the Ready state, waiting for the scheduler to actually give it CPU time — on a busy machine, this might mean sharing time with dozens of other Ready processes (lessons 4–5).
Once scheduled, it starts running. Reading the script file from disk means the process's inode is looked up (lesson 10), and the read itself is a blocking system call — moving the process to Waiting until the disk's completion interrupt fires (lesson 11), at which point it goes back to Ready and eventually gets scheduled again.
As it executes, code and data it touches get paged into RAM on demand — mostly fast, routine minor page faults (lesson 7), unless memory pressure has pushed some of its pages out to swap, in which case a major page fault (and a real slowdown) is possible.
If the program spawns threads to do work concurrently, those threads share its heap and global memory, which means any shared, mutable state they touch needs a mutex or semaphore to avoid a race condition (lesson 8) — and if two threads acquire multiple locks in inconsistent orders, deadlock becomes possible (lesson 9).
When the process finishes, the OS reclaims its memory (returning its pages to the pool of free frames) and its other resources — including, eventually, its inode's directory entry if the script itself is later deleted (lesson 10).

Why this synthesis is worth doing explicitly

Learning each mechanism in isolation makes it easy to file each one away as a separate, disconnected fact. Tracing one real, ordinary action through every layer makes the actual dependency structure visible: scheduling only matters because multiple processes compete for a CPU; page faults only happen because of virtual memory; virtual memory only needs an MMU because processes need real isolation. None of these ideas is really separate from the others — they're one coherent system, and most of the debugging skill this domain builds toward is being able to mentally trace this same sequence when something in a real system goes wrong.

Where this domain connects to the rest of the curriculum

Linux & the Command Line's ps, top, and kill commands are a direct, practical interface onto the process states and scheduling covered here. Networking Fundamentals' discussion of sockets and blocking network calls is the same I/O and interrupt model from lesson 11, applied to a network card instead of a disk. And the memory bugs covered in passing throughout Python, JavaScript, and other language domains — leaks, use-after-free classes of bug in lower-level languages — are exactly the stack/heap mechanics from lesson 3, now with the underlying "why" attached.

Putting it together: what happens when you run a program

Intermediate

3 min read

The walkthrough: running `python script.py`

Following one ordinary command from keystroke to output touches nearly every idea covered in this domain — this lesson is a deliberate synthesis, not new material.

Step by step

The shell reads your command and, to actually run it, asks the kernel to create a new process via the fork() system call (lesson 1) — this duplicates the shell's own process as a starting point.
exec() replaces that new process's memory with the target program's actual code, setting up its virtual address space: code, data, heap, and stack regions (lesson 3), all backed by virtual memory the MMU will translate on every access (lesson 6).
The process enters the Ready state, waiting for the scheduler to actually give it CPU time — on a busy machine, this might mean sharing time with dozens of other Ready processes (lessons 4–5).
Once scheduled, it starts running. Reading the script file from disk means the process's inode is looked up (lesson 10), and the read itself is a blocking system call — moving the process to Waiting until the disk's completion interrupt fires (lesson 11), at which point it goes back to Ready and eventually gets scheduled again.
As it executes, code and data it touches get paged into RAM on demand — mostly fast, routine minor page faults (lesson 7), unless memory pressure has pushed some of its pages out to swap, in which case a major page fault (and a real slowdown) is possible.
If the program spawns threads to do work concurrently, those threads share its heap and global memory, which means any shared, mutable state they touch needs a mutex or semaphore to avoid a race condition (lesson 8) — and if two threads acquire multiple locks in inconsistent orders, deadlock becomes possible (lesson 9).
When the process finishes, the OS reclaims its memory (returning its pages to the pool of free frames) and its other resources — including, eventually, its inode's directory entry if the script itself is later deleted (lesson 10).

Putting it together: what happens when you run a program

The walkthrough: running `python script.py`

Step by step

Why this synthesis is worth doing explicitly

Where this domain connects to the rest of the curriculum

Further reading

Putting it together: what happens when you run a program

The walkthrough: running `python script.py`

Step by step

Why this synthesis is worth doing explicitly

Where this domain connects to the rest of the curriculum

Further reading