Skip to content

CONCEPT Cited by 1 source

Process (OS)

Definition

A process is an instance of a program being executed by an operating system. It is the OS's fundamental unit of isolation for running code: each process has its own address space (code + data + heap + stack), its own file descriptors, its own page table, and its own scheduling state. Modern OSes manage many processes simultaneously via context switching on a shared CPU, giving the illusion of simultaneous execution.

Process states

Every process moves through a small state machine managed by the OS scheduler:

  • Running — currently executing on a CPU core.
  • Ready — eligible to run, waiting for CPU time.
  • Waiting (blocked) — paused waiting on I/O (disk, network), a lock, or a signal; not eligible for CPU until the event arrives.
  • Killed (terminated) — finished executing, resources being reclaimed.

Transitions: Running → Ready (time slice expired), Running → Waiting (I/O or lock needed), Waiting → Ready (I/O completed), Ready → Running (scheduled onto CPU), Running → Killed (process exited).

Process vs thread

A process owns its own address space; threads within a process share the process's address space (except for their own stacks). This makes thread switching ~5× cheaper than process switching (~1 μs vs ~5 μs) at the cost of losing isolation: a bug in one thread can corrupt another thread's data in the shared address space.

Creation

Processes are created via two canonical system calls (concepts/fork-execve):

  • fork() — clones the calling process into a nearly-identical child process (same memory contents, same open file descriptors).
  • execve() — replaces the current process's program image with a new one loaded from disk.

The canonical spawn-a-program sequence is fork() then, in the child, execve(binary_path, ...). On Linux both are thin wrappers around the unified clone() system call.

At boot, a single process is initiated; all other processes are descendants of it via fork() (Source: [[sources/2026-04-21- planetscale-processes-and-threads]]).

Database architectural role

The process abstraction is the substrate under process-per-connection databases like Postgres: every client connection forks a new OS process (PostMaster → backend process), inheriting the OS's memory-isolation guarantees at the cost of ~5–10 MB per backend plus the context-switch tax.

Seen in

  • sources/2026-04-21-planetscale-processes-and-threads — Ben Dicken's canonical wiki definition of the process abstraction via an interactive-article pedagogical piece. Canonicalises the process states (Running / Ready / Waiting / Killed), the role of time slicing, and process-per-connection as Postgres's architectural choice: "Postgres is implemented with a process-per-connection architecture. Each time a client makes a connection, a new Postgres process is created on the server's operating system. There is a single 'main' process (PostMaster) that manages Postgres operations, and all new connections create a new Process that coordinates with PostMaster."
Last updated · 470 distilled / 1,213 read