Process

A process is an instance of a program in execution — the living, dynamic counterpart to the static executable file stored on disk. Where the executable is a description of what a program could do, the process is what it actually does: a container of memory, a set of registers, a program counter, a stack, a heap, and a collection of operating system resources (file descriptors, sockets, permissions) that together constitute a running program. The process is the fundamental unit of execution in modern operating systems, the boundary within which a program operates and the boundary that protects it from other programs.

The concept of a process was not present in early computing. The first computers ran one program at a time, from start to finish, with no need for isolation or multiplexing. The process abstraction emerged with time-sharing systems in the 1960s, which needed to run multiple programs concurrently on a single machine. The process provided the isolation mechanism: each program got its own memory space, its own register set, and its own resource table, and the operating system switched between processes fast enough to create the illusion of simultaneity.

The Process as Container

A process is defined by its address space — the range of virtual memory addresses it can access. This address space contains the program code (the text segment), initialized and uninitialized global data (the data and BSS segments), the heap for dynamic allocation, and the stack for local variables and function calls. The address space is private: one process cannot directly read or write another process's memory without explicit inter-process communication mechanisms. This privacy is the foundation of system stability and security.

But a process is more than memory. It is also a scheduling entity — the unit that the operating system's scheduler assigns to a CPU. Each process has a state (running, ready, blocked, terminated), a priority, and a set of CPU registers that must be saved and restored during context switches. The process abstraction allows the operating system to pause one program, run another, and resume the first without either program noticing the interruption.

The process also carries identity: a process ID, a user ID, a group ID, and a set of permissions that determine what resources it can access. These identity attributes are the operating system's mechanism for enforcing security policy. A process running as a normal user cannot access another user's files; a process running as root can access almost anything. The process is the unit of both execution and accountability.

Processes, Threads, and the Concurrency Model

The traditional process model — one address space, one flow of control, one stack — was sufficient for sequential programs but became a bottleneck for concurrent ones. Creating a new process is expensive (forking copies the entire address space), and processes communicate through slow inter-process communication mechanisms. The thread was introduced as a lighter concurrency unit: multiple threads share the same address space and resources but have their own stacks and program counters. Threads can be created faster, communicate through shared memory, and enable fine-grained parallelism within a single program.

This evolution reveals a systems pattern: the process is a security boundary, while the thread is a performance optimization. The process provides isolation; the thread provides concurrency. The two are not the same, and conflating them leads to design errors. A multi-threaded program shares the same security identity across all its threads — a vulnerability if one thread is compromised. A multi-process program has stronger isolation but higher communication overhead. The choice between processes and threads is a trade-off between security and performance, and the correct choice depends on the threat model.

The Process Lifecycle and the Operating System

A process begins with a fork or spawn operation, in which the operating system creates a new process from an existing one or from an executable file. The new process inherits some resources from its parent (environment variables, file descriptors, signal handlers) and receives others from the operating system (a new process ID, a fresh address space). The process then executes its program, makes system calls, allocates memory, creates threads, and eventually terminates — either by completing its program, by calling an exit function, or by being killed by a signal or the operating system.

Throughout this lifecycle, the process is managed by the operating system, which tracks its state, schedules its CPU time, manages its memory, and handles its I/O requests. The process is not autonomous; it is a client of the operating system, dependent on its services for every significant operation. This dependency is not a limitation but a feature: it is what enables the operating system to enforce fairness, security, and resource limits across competing processes.

The process is the most successful abstraction in operating systems precisely because it is the most honest. It does not pretend that programs are isolated atoms of computation. It acknowledges that every running program is a consumer of shared resources, a potential threat to stability, and a participant in a complex ecosystem of competing demands. The process abstraction gives the operating system the vocabulary and the mechanisms to manage this ecosystem: to allocate, to protect, to schedule, and to kill. Without the process, there is no operating system. With it, we have built the infrastructure that runs the world.