Processes vs Threads

A thread is a lightweight unit of execution inside a process; a process is the OS unit that owns its own virtual memory, file handles, and CPU time. Understanding the difference is the foundation of concurrency in Python, because it decides what state you can share and how expensive each unit of parallelism is.

Key Differences

Aspect	Thread	Process
Memory	shared with parent and siblings	private; must send data explicitly
Creation cost	cheap (microseconds)	expensive (milliseconds, copy/fork)
Failure isolation	one crash can take the whole process	one crash leaves others running
Data passing	direct (same heap)	pickling through queues/pipes
CPU parallelism	limited by the GIL in CPython	true parallelism across cores

The Same Task, Two Ways

import threading
import time

def work(n):
    time.sleep(n)   # simulated work

threads = [threading.Thread(target=work, args=(1,)) for _ in range(4)]
[t.start() for t in threads]
[t.join() for t in threads]
print("threads done")

import multiprocessing

def work(n):
    time.sleep(n)

procs = [multiprocessing.Process(target=work, args=(1,)) for _ in range(4)]
[p.start() for p in procs]
[p.join() for p in procs]
print("processes done")

Both snippets finish after about 1 second, but the thread version shares the interpreter's memory (and its Global Interpreter Lock), while the process version runs four independent interpreters that can truly execute in parallel.

When to Choose Which

Choose threads when tasks are I/O-bound, when you need to share mutable state without copying it, or when the work is small enough that process startup is not worth it.
Choose processes when the work is CPU-bound, when isolation protects your main application from a crash, or when a plugin or extension releases the GIL.

Summary

Threads share memory and are cheap but serialized by the GIL for CPU work; processes are isolated and parallel but expensive to create and communicate with. Pick the model based on what the tasks wait on, not on which one sounds heavier.