Process vs Thread

The OS represents a process with a Process Control Block (PCB) that holds its virtual address space, list of open file descriptors, signal handlers, environment variables, and CPU register state. Because each process has its own virtual address space, a bug in one process (like a null pointer dereference) cannot corrupt another process's memory. This isolation is why web browsers run each tab as a separate process.

Threads within a process share the heap, global/static variables, and open file descriptors. Each thread has its own stack (for local variables and function call frames) and CPU registers. This shared memory is what makes threads fast for communication — no serialization needed — but also what makes concurrent programming hard. A thread that corrupts the heap takes down the entire process.

When the OS switches between processes, it must save and restore the entire CPU state AND flush and reload the TLB (Translation Lookaside Buffer) because the virtual-to-physical memory mapping changes. Thread context switches within the same process are lighter — the TLB doesn't need flushing because threads share the same address space. This is why thread-per-request servers can be faster than process-per-request at high concurrency.

Prefer multiple processes when you need strong isolation — a crash or security exploit in one worker should not affect others (e.g., browser tabs, Nginx worker processes). Prefer threads when tasks share large data structures and communication overhead matters (e.g., a game engine where physics, rendering, and audio all operate on the same scene graph). Many modern systems use both: process-level isolation at the boundary, thread-level parallelism inside.