Process versus Thread

The table below is the whole lesson in one screen. Every row follows from one fact: threads share an address space and processes do not. Sharing makes communication and switching cheap and makes failure and corruption shared; separation makes them expensive and contained. Numbers are typical Linux x86-64 figures, order-of-magnitude only; measure on your platform before quoting them.

Isolation is enforced by the MMU. A process that dereferences a bad pointer takes a page fault, the kernel finds no mapping, and sends SIGSEGV to *that* process. Its siblings never notice. That is why Chrome pays for a process per site: a renderer exploited by one page cannot read another page’s cookies from memory, and a renderer crash shows a sad tab, not a dead browser. It is why nginx and PostgreSQL survive a crashing worker with one reconnect rather than an outage.

Threads have no such wall. A segfault in one thread is a signal to the process; an uncaught exception terminates the process; a thread that corrupts the heap allocator’s metadata takes down whatever thread next calls malloc. Memory-safe languages remove the corruption but not the shared fate: an out-of-memory error or a stuck lock in one Java thread affects every thread in the JVM. The rule of thumb: put things that must not take each other down in separate processes, and things that must share large state cheaply in threads.

Between threads, communication is a memory write plus a synchronisation primitive: a lock-protected queue, an atomic flag, a condition variable. Handing a 1 MB buffer to another thread costs a pointer. Between processes it costs a copy through the kernel (pipe, socket, message queue — see IPC: Deliberate Holes in Process Isolation) or the up-front work of mapping a shared-memory segment (Shared Memory: Zero Copies, Zero Protection) and then the *same* synchronisation problems as threads, because shared memory is shared memory.

Switching between two threads of the same process keeps the page tables and the TLB; switching between processes loads a new page-table root, which on x86 flushes the TLB unless the CPU tags entries with a process-context id (PCID, and ASIDs on ARM), and either way the new process starts with cold caches. The direct cost difference is small (a microsecond or so); the indirect cost — TLB misses and cache misses in the first milliseconds after the switch — is what shows up in benchmarks. See Context Switching.

Browsers: process per site for security isolation, threads inside each renderer for parsing, layout, JavaScript and compositing. nginx: one process per core, each running a single-threaded event loop, because the work is I/O-bound and the workers share nothing but the listening socket. PostgreSQL: process per connection, historically for robustness and portability, with explicit shared memory for the buffer pool — the reason PostgreSQL connections are expensive and everyone runs a pooler. MySQL, SQL Server, most JVM services: threads, because the buffer pool and caches are simply the heap.

Node.js: one process runs one event loop; to use eight cores you run eight processes (cluster) or worker threads with separate V8 isolates that share nothing by default. CPython: threads for I/O concurrency, processes for CPU parallelism because of the GIL in the default build — see How C++, JavaScript and Python Map onto the OS. Go, Java virtual threads, Erlang: one process, a few kernel threads, millions of cheap user-level tasks. None of these is the "right" answer; each is a position on the isolation-versus-sharing line chosen for its workload.