⚖️ Processes vs Threads vs Async

The Three Models in One Breath

• multiprocessing — many processes, each with its own interpreter and its own GIL. The only standard-library way to get true CPU parallelism in pure Python. Memory is isolated; data crosses via pickling and IPC. (This is what the whole site is about.)
• threading — many threads in one process, sharing memory. The single GIL means they interleave rather than parallelize on CPU, but the GIL is released on blocking I/O — so threads are great for overlapping waiting.
• asyncio — a single thread running an event loop that juggles thousands of tasks, switching only at await. Cheapest per task, but every library in the path must be async-aware.

The Big Comparison

The process column is the one this site cares about — read it first, then contrast.

The Decision, as a Flowchart

Same Task, Three Ways

concurrent.futures is the great unifier: the same code becomes threads or processes by swapping one class name. That makes it trivial to A/B a workload and let the numbers tell you which model your problem actually wants. See Pattern 2 for the full ProcessPoolExecutor treatment.

from concurrent.futures import ThreadPoolExecutor, ProcessPoolExecutor

def work(item):
    ...   # do something with item
    return item

if __name__ == "__main__":            # REQUIRED for the process pool (spawn re-imports)
    items = range(100)

    # I/O-bound → threads (shared memory, cheap, works with sync libs)
    with ThreadPoolExecutor(max_workers=16) as pool:
        results = list(pool.map(work, items))

    # CPU-bound → processes (true parallelism; `work` & args must pickle)
    with ProcessPoolExecutor() as pool:            # same API, one word changed
        results = list(pool.map(work, items))

And the async equivalent, which lives in its own world with await:

import asyncio, httpx   # note: an ASYNC http client, not `requests`

async def fetch(client, url):
    r = await client.get(url)          # yields control here — loop runs others
    return r.status_code

async def main(urls):
    async with httpx.AsyncClient() as client:
        return await asyncio.gather(*(fetch(client, u) for u in urls))

if __name__ == "__main__":
    asyncio.run(main(["https://example.com"] * 1000))   # 1000 tasks, one thread

The Subtleties That Bite (Especially From the Process Side)

• The serialization / pickling tax. Every argument in and every result out is pickled, copied across an OS boundary, and rebuilt. For tiny tasks that overhead can dwarf the computation — processes only win when each task is genuinely CPU-heavy. Full treatment in Pattern 8.
• Not everything is picklable. Lambdas, locally-defined functions, open sockets, file handles, and DB connections can't cross a process boundary — so a worker target must be a top-level function and its arguments must be plain data. Threads and async have no such restriction, since they share the same objects.
• The start method and the __main__ guard. On macOS and Windows the default is spawn: a fresh interpreter per worker that re-imports your module. Without if __name__ == "__main__": around the launch, each child re-runs the launch on import — endless process explosion. This has no analogue in threading or async. See Pattern 7.
• Oversubscription. A subtle process-only trap: a ProcessPoolExecutor with 8 workers, each running NumPy on top of a BLAS library that itself spawns 8 native threads, gives you 64 threads fighting over 8 cores — slower than either alone. Pin it with OMP_NUM_THREADS=1 (or the BLAS-specific var) so the two layers of parallelism don't multiply.

Hybrid Is Normal — Pick the Model Per Workload

The bridge from an async server to real cores is loop.run_in_executor. Await a CPU-bound function as if it were async; under the hood it runs in a separate process and the event loop keeps serving other requests:

import asyncio
from concurrent.futures import ProcessPoolExecutor

def crunch(n):                     # top-level + picklable → safe for a process pool
    total = 0
    for i in range(n):
        total += i * i
    return total

async def handle_request(loop, pool, n):
    # offload CPU work to a worker process; the event loop stays free meanwhile
    result = await loop.run_in_executor(pool, crunch, n)
    return result

async def main():
    loop = asyncio.get_running_loop()
    with ProcessPoolExecutor() as pool:                 # a GIL per worker → real parallelism
        results = await asyncio.gather(
            *(handle_request(loop, pool, 30_000_000) for _ in range(4))
        )
    print(results)

if __name__ == "__main__":         # REQUIRED — the pool spawns worker processes
    asyncio.run(main())

Key Takeaways