Process vs thread: isolated, or shared memory?

A process is an independent running program with its own isolated memory space — one process cannot read or corrupt another’s memory, and they communicate only through explicit channels (pipes, sockets, shared-memory segments). A thread is a unit of execution inside a process, and all threads in a process share the same memory — the same heap, the same globals, the same open files. That one difference — isolated versus shared memory — cascades into everything: how expensive they are to create, how they communicate, and what happens when one of them crashes.

Real systems combine them. A common shape: run several worker processes for isolation and true multi-core parallelism (one crashing worker doesn’t kill the rest), and within each worker use threads (or async) to handle many concurrent IO-bound connections cheaply. This is exactly how many production web servers are structured — a pool of processes, each running an event loop or thread pool. There’s also a third concurrency model that sidesteps both: a single-threaded event loop (async/await) that interleaves many IO-bound tasks on one thread with no locks and no context-switch cost — great for IO-bound work, useless for CPU-bound work (which still wants processes).

Threads’ shared memory is their superpower and their curse. Communication is nearly free — one thread writes a variable, another reads it, no serialization, no copying. But that same sharing is why threads need synchronization: two threads touching the same data at once cause race conditions, so you add locks — and locks bring their own hazards (contention, and deadlock if two threads grab locks in different orders). Processes avoid all of this by construction: with isolated memory there’s nothing to race on, but you pay for communication with IPC and serialization overhead. You’re choosing between "fast to talk, dangerous to share" and "safe by isolation, costly to talk."

One infamous wrinkle: in CPython, the Global Interpreter Lock (GIL) lets only one thread execute Python bytecode at a time, so multithreading does not give you CPU parallelism in pure-Python code — threads still help IO-bound work (the GIL is released during IO), but CPU-bound Python needs multiprocessing to actually use multiple cores. This is why "use processes for CPU-bound work" is near-gospel in Python, while languages without a GIL (Java, Go, C++, Rust) get real multi-core parallelism from threads directly.

You’re serving thousands of simultaneous HTTP requests. Handling each in its own process would be safe but wasteful — processes are heavy to create and switch, and thousands of them would exhaust memory. Handling all of them as threads in one process is cheap and lets them share caches directly, but one bad request that segfaults or leaks could take down every connection at once, and in Python the GIL would cap CPU throughput anyway.

So production servers layer both: a small pool of worker processes (one per core, for isolation and true parallelism — a crash kills one worker, and the manager restarts it without dropping the others), and within each worker, threads or an async event loop to juggle many IO-bound connections concurrently at low cost. Processes give you fault isolation and cores; threads/async give you cheap concurrency. Neither alone is right — the architecture uses each for what it’s good at.