Learning Question
What exactly is a process, and why is it different from a program or executable file?
A program is a set of instructions and data that can be run.
An executable file is a stored representation of a program.
A process is a running instance managed by the operating system.
The first mental model is:
A process is the operating system’s runtime record for one running instance of a program.
Program, Executable, Process
These three concepts are related, but they are not the same.
| Concept | What It Is |
|---|---|
| program | the abstract code and behavior that can be run |
| executable file | a file representation that the OS can load |
| process | one active running instance with OS-managed state |
One executable file can create many processes.
If the same command is started twice, the system does not usually create one shared set of local variables and one shared stack.
It creates separate process instances.
Each process has its own execution state, address space, open resources, and lifetime.
Process Identity
The operating system gives each process an identity.
On Unix/Linux systems, this is commonly a process ID, or PID.
The PID lets the system and other tools refer to that running instance.
For example, tools can list a process, inspect it, send it a signal, wait for it, or show its resource usage.
The PID is not the program.
It is an identifier for one OS-managed instance of a program while that instance exists.
Process State
A process has state beyond the code it executes.
Important examples include:
- current instruction and register state
- virtual memory mappings
- stack and heap regions
- open file descriptors
- current working directory
- environment variables
- user and group identity
- signal handlers and signal masks
- scheduling state
- parent process relationship
- exit status after termination
This is why “the process” is larger than “the code.”
The code describes what can happen.
The process records what is happening in one running instance.
Running, Runnable, Blocked, Exited
A process may not be actively executing at a given moment.
It may be:
- running on a CPU
- runnable but waiting for CPU time
- blocked while waiting for I/O or another event
- stopped by a signal or debugger
- exited but not yet fully reaped by its parent
From the program’s source-code point of view, it may look like execution simply moves from one statement to the next.
From the OS point of view, the process moves through states depending on CPU scheduling, waits, signals, and resource availability.
Per-Process Resources
The operating system attaches resources to a process.
For example, when a process opens a file, it receives a file descriptor.
That descriptor is meaningful inside the process because the OS has associated it with an open file description or another open resource.
When a process exits, the operating system can close its remaining descriptors, release its address space, and record its exit status.
This cleanup is possible because resources are tracked through OS-level process state.
Parent and Child Processes
Unix/Linux systems organize processes into parent-child relationships.
A shell starts commands as child processes.
A program may also create child processes itself.
The parent relationship matters because a parent can often observe a child’s exit status.
It also matters for inherited resources.
For example, a child process may inherit open file descriptors from its parent unless those descriptors are configured not to survive creation or program replacement.
This is one reason command-line pipelines and redirection work as process-level behavior rather than as magic inside the shell command string.
Process Is a Boundary
A process is also a boundary.
By default, one process cannot directly read or write another process’s private memory.
It cannot simply jump into another process’s functions.
It communicates through operating-system mechanisms such as pipes, sockets, files, signals, shared memory, or other IPC features.
This boundary is central to OS protection:
A process is not only a unit of execution. It is also a unit of isolation, ownership, scheduling, and lifetime.
Core Mental Model
When a program is launched, the operating system creates or prepares a process.
That process contains the runtime state needed to execute and manage one instance of the program.
When thinking about a runtime problem, ask:
Am I reasoning about the executable file, the source program, or one specific process instance with its own OS-managed state?
Final Summary
A process is the operating system’s managed running instance of a program.
It has identity, memory, CPU state, open resources, permissions, scheduling state, relationships, and lifetime.
Keeping the process separate from the executable file prevents confusion about how the same program can run many times at once and why each run has its own state.