In operating systems, a process is a running instance of a program, together with the private memory, open resources, security identity and execution state that the kernel assigns to it. A program is a passive file on disk; a process is that program brought to life and tracked by the kernel as a distinct unit of work.
The process is one of the OS fundamentals on which almost everything else rests. Scheduling, memory protection, permissions and resource accounting are all organized around processes, and each one receives a numeric process identifier (PID) that tools and other processes use to refer to it.
What the kernel keeps for each process
For every process the kernel maintains a data structure usually called the process control block, named task_struct in Linux and EPROCESS in the Windows kernel. It records everything needed to pause the process and later resume it exactly where it stopped.
| Component | Content | Purpose |
|---|---|---|
| Virtual address space | Code, data, heap and stack regions | Private memory isolated from other processes |
| Threads | One or more execution contexts with registers and stacks | Units the scheduler actually runs |
| Resource table | File descriptors or handles, sockets, pipes | Access to files, devices and network |
| Security context | User ID, groups or access token, privileges | Decides what the process may do |
| Accounting data | CPU time, memory use, priority, limits | Scheduling decisions and quotas |
| Relationships | Parent PID, child list, session, job | Lifecycle management and signals |
The address space is virtual: each process sees addresses that the memory management unit translates through per-process page tables. This is why two processes can use the same address without interfering, and why a crash in one process normally does not corrupt another.
Process states and the lifecycle
A process moves through a small set of states during its life. The scheduler and interrupt handlers move it between them as it waits for input, receives CPU time or finishes. The table summarizes the classic model, which real kernels refine with additional substates.
| State | Meaning | Typical transition |
|---|---|---|
| New | Being created, resources being allocated | Becomes ready once set up |
| Ready | Able to run, waiting for a CPU | Dispatched by the process scheduler |
| Running | Executing instructions on a CPU core | Preempted, blocks or exits |
| Waiting or blocked | Waiting for I/O, a lock or an event | Returns to ready when the event arrives |
| Terminated | Finished, exit status not yet collected | Removed after the parent reads the status |
Moving the CPU from one process to another requires a context switch: saving registers, switching page tables and restoring the next context. A switch typically costs a few microseconds including cache and translation buffer effects, which is why frequent switching reduces throughput.
How processes are created and ended
Processes are created by other processes through system calls, which forms a tree rooted in the first user process, such as init or systemd on Linux and launchd on macOS. Unix-like systems use a two-step model: fork duplicates the caller, using copy-on-write so memory is copied only when modified, and exec replaces the copy with a new program. Windows uses a single CreateProcess call that builds the new process and loads the program in one step.
A process ends by calling exit, by returning from its main function or by being killed through a signal or a termination call. The kernel then releases memory and handles, but keeps a small record with the exit status until the parent collects it. A process whose parent has not collected that status is a zombie; a process whose parent has died is an orphan and is adopted by a system process.
Parent and child relationships differ across platforms. On Unix-like systems the parent receives a SIGCHLD signal when a child ends and is expected to call wait. Windows keeps a weaker link: a parent holds a process handle that it can wait on, and processes can be grouped into job objects so that an entire tree is limited or terminated together, a mechanism similar to Linux control groups.
Process compared with thread, program and container
The process is the unit of isolation and resource ownership, while the thread is the unit of execution. Confusing the two leads to wrong assumptions about memory sharing and crash behavior.
| Concept | Shares memory | Isolation level | Typical use |
|---|---|---|---|
| Program | Not applicable | None; it is a file | Stored executable code |
| Process | No, by default | Separate address space and identity | Running application or service |
| Thread | Yes, within its process | None between threads of one process | Parallel work inside an application |
| Container | No | Processes grouped with namespaces and limits | Packaged, isolated services |
Because processes do not share memory, they cooperate through inter-process communication such as pipes, sockets, shared memory segments and message queues. Modern browsers deliberately split work into many processes so that a compromised or crashed tab cannot reach the rest of the browser.
Common problems with processes
- Zombie accumulation happens when a parent never collects exit statuses, slowly consuming PID entries.
- Resource leaks of file descriptors or handles eventually make a long-running process fail to open files.
- Fork bombs create processes exponentially until the system stalls; per-user process limits prevent this.
- Excess privileges let a compromised process do more damage, so services should run under minimal accounts.
- Orphaned background processes may keep files locked or ports occupied after the main application closes.
Administrators inspect processes with tools such as ps, top and Task Manager, and end them gracefully before forcing termination so that data can be saved and released cleanly.
In everyday language
A program is like a recipe written in a book. A process is someone actually cooking that recipe in a kitchen, with their own counter space, ingredients and utensils. Two cooks can follow the same recipe at the same time without mixing up their bowls.
The operating system is the kitchen manager. It decides who gets the stove next, makes sure no cook takes another cook’s ingredients and cleans up when a cook leaves. Every app you open runs as at least one process.
Seen in the real world
A web server running on Linux begins rejecting requests after several days of uptime, logging the error too many open files. The administrator lists the server process with ps, then inspects its open descriptors and finds more than 60,000 entries, nearly all of them network sockets that were never closed.
The per-process limit is set to 65,536 descriptors, so the process has simply exhausted its resource table. A code fix closes sockets after timeouts, and the service manager is configured to restart the process if it exits unexpectedly. The outcome is a stable server whose descriptor count stays below 2,000, and the team adds monitoring so the next leak is caught early.