🏭 Pattern 1: Process Basics

The Problem

The Sequential Baseline (❌ One Core)

import time

def burn(n):
    total = 0
    for i in range(n):        # pure-Python loop — the GIL cannot release here
        total += i
    return total

start = time.perf_counter()
for _ in range(4):
    burn(30_000_000)          # ~1s each, run back-to-back
print(f"{time.perf_counter() - start:.1f}s")   # ~4s on any machine, 1 core busy

Threads won't help: the GIL serializes pure-Python bytecode, so four threads still take ~4s. Processes are the only standard-library way past it — each child is a full interpreter with its own GIL.

The Four Verbs

Every process you launch follows the same lifecycle. It mirrors threads — but the process runs in its own private memory, not shared with you.

• Construct: p = mp.Process(target=fn, args=(...)) — builds the object; nothing runs yet.
• Start: p.start() — spins up a new OS process (a fresh Python interpreter) that runs fn. Returns immediately.
• Run: the child executes fn on its own core, in its own memory, with its own GIL.
• Join: p.join() — blocks the caller until the child has exited. Optional timeout=.

Three read-only attributes you'll reach for constantly:

• p.pid — the OS process id (None before start()).
• p.is_alive() — True between start() and exit.
• p.exitcode — None while running, 0 on clean exit, > 0 for a nonzero sys.exit, and negative if killed by a signal (e.g. -9 = SIGKILL). Your first stop when a child "just died".

The Rule You Can't Skip: if __name__ == "__main__"

Unlike threads, launching a process must be guarded. On macOS and Windows (the spawn start method) each child re-imports your module to rebuild the worker. If your start() call sits at module top level, every child re-runs it on import — spawning children that spawn children.

import multiprocessing as mp

def worker(name):
    print(f"{name} running in pid {mp.current_process().pid}")

# ✅ this block runs ONLY in the original process, never on re-import
if __name__ == "__main__":
    p = mp.Process(target=worker, args=("A",))
    p.start()
    p.join()
    print("exitcode:", p.exitcode)   # 0

Getting a Return Value: You Get NONE

Here's where processes diverge hard from threads. A Process gives you no way to read what target returned — the return value is discarded when the child exits. And because the child has separate memory, the thread trick of writing into a shared dict does not work: the child mutates its own private copy, which vanishes on exit.

import multiprocessing as mp

results = {}

def fetch(name):
    results[name] = f"data-{name}"   # writes the CHILD's private copy — parent never sees it

if __name__ == "__main__":
    procs = [mp.Process(target=fetch, args=(n,)) for n in "ABC"]
    for p in procs: p.start()
    for p in procs: p.join()
    print(results)   # {} — EMPTY. The child's memory was thrown away.

You have exactly two ways to get data back across the memory boundary:

import multiprocessing as mp

def fetch(name, q):
    q.put((name, f"data-{name}"))     # push result onto the shared queue

if __name__ == "__main__":
    q = mp.Queue()
    procs = [mp.Process(target=fetch, args=(n, q)) for n in "ABC"]
    for p in procs: p.start()
    for p in procs: p.join()
    print({k: v for k, v in (q.get() for _ in procs)})   # {'A': 'data-A', ...}

from concurrent.futures import ProcessPoolExecutor

def fetch(name):
    return f"data-{name}"             # a plain return — the pool collects it

if __name__ == "__main__":
    with ProcessPoolExecutor() as pool:
        print(list(pool.map(fetch, "ABC")))   # ['data-A', 'data-B', 'data-C']

The Common Bug: Start-and-Join in One Loop

Same pitfall as threads, same fix. If you start() and join() a process inside the same loop iteration, you wait for each child to finish before launching the next — perfectly sequential, and you've paid the process-startup cost for nothing.

import multiprocessing as mp, time

def burn(n):
    total = 0
    for i in range(n):
        total += i

if __name__ == "__main__":
    # ❌ SEQUENTIAL: each join blocks before the next start
    for _ in range(4):
        p = mp.Process(target=burn, args=(30_000_000,))
        p.start()
        p.join()          # waits here — next process hasn't started yet

    # ✅ PARALLEL: start them all, THEN join them all
    procs = [mp.Process(target=burn, args=(30_000_000,)) for _ in range(4)]
    for p in procs: p.start()
    for p in procs: p.join()   # total ≈ time of one, not four

Daemons and Termination

Two knobs you'll meet early, both about lifecycle rather than results:

• daemon=True — set before start(). A daemon child is killed abruptly when the parent exits (no cleanup, no finally, no join of its children). Good for a background heartbeat you don't care about losing; dangerous for anything holding a resource. Non-daemon (the default) children keep the interpreter alive until they finish.
• p.terminate() — sends SIGTERM to the child; p.kill() sends SIGKILL. Both are blunt: the child stops without running cleanup, and any half-written Queue data can corrupt the queue. Always join() after terminating to reap the zombie.

import multiprocessing as mp, time

def loop_forever():
    while True:
        time.sleep(0.5)

if __name__ == "__main__":
    p = mp.Process(target=loop_forever, daemon=True)
    p.start()
    time.sleep(1)
    p.terminate()         # SIGTERM — abrupt stop
    p.join()              # reap it; now p.exitcode is negative (signalled)
    print(p.exitcode)     # -15  (== -SIGTERM)

Key Takeaways