Learning Question
Why is a process a runtime container rather than a code file?
A process is one live running instance managed by the operating system. It contains runtime state created from code artifacts and startup context, but it is not itself the source file, executable file, or bytecode file.
The same executable can produce many processes:
app.exe -> process 1
app.exe -> process 2
app.exe -> process 3Each process can have different arguments, environment variables, open files, current working directory, memory state, timing, inputs, and outputs.
The file may be the same. The runs are different.
What a Process Contains
A process is not only “the code in memory.”
It is a managed runtime container that can include:
- process identity
- virtual address space
- mapped code and data
- heap and stack memory
- one or more threads
- command-line arguments
- environment variables
- current working directory
- open files, sockets, pipes, or handles
- permissions and user identity
- signal or termination state
- exit status after it finishes
Some of those parts come from the executable. Many come from the operating system, parent process, runtime, or interactions after startup.
Why Code File and Process Must Stay Separate
If the executable file changes on disk, an already running process does not automatically become identical to the new file.
If the same executable is started twice, the two processes do not share the same whole runtime state.
If one process crashes, the file on disk can remain unchanged.
If a process writes output, accepts network connections, allocates memory, or opens files, that state belongs to the running instance, not to the stored code artifact.
This distinction keeps the file/run boundary clear:
code artifact = stored possibility
process = one live execution containerManaged Runtimes Still Need Processes
Managed runtime systems do not remove the process boundary.
A Java application may feel like “the class is running”, but the operating system sees a java process. A Python script may feel like “the script is running”, but the operating system sees a python process.
Inside that process, the runtime may create language-level objects, stack frames, threads, modules, classes, and managed memory. The process is still the operating-system container around that runtime.
What This Chapter Leaves to the OS Collection
This chapter does not explain process scheduling, process creation APIs, virtual memory implementation, file descriptors, signals, or permissions in depth.
Those topics belong in How Operating Systems Support Running Programs.
The point here is the role:
stored artifact -> process startup -> live runtime containerMental Model
When you say a program is running, identify the process or runtime process:
Which process exists?
What artifact helped create it?
What runtime state is inside it now?
What behavior can it perform while it remains alive?The process is where one run happens. The file is only one input to creating that run.