What's the difference between a process and a thread?

Outline6 turns

1. What's the difference between a process and a thread?
2. A process is an independent program with its own memory space; a thread is a un…
3. So when would I choose multiprocessing over multithreading in Python specifical…
4. In CPython the Global Interpreter Lock (GIL) means only one thread executes Pyt…
5. Got it. And how does that relate to asyncio?
6. asyncio is single-threaded cooperative concurrency: one thread, one event loop,…

Search

Ask

TL;DR

Listen6 passages

Read aloud, a different voice per speaker, synthesized on your device: the first listen downloads the voice once, and the page highlights what is being said as it goes. Tap any sentence to listen from there. Code blocks are announced rather than spelled out.

[{"index":0,"anchor":"t0","origin":"page","voice":"user","text":"What's the difference between a process and a thread?"},{"index":1,"anchor":"t1","origin":"page","voice":"assistant","text":"A process is an independent program with its own memory space; a thread is a unit of execution that lives inside a process and shares that process's memory with sibling threads. Creating a process is heavier (new address space); creating a thread is lighter (shared address space). Threads communicate through shared memory, which is fast but requires synchronization to avoid races; processes communicate through IPC mechanisms like pipes or sockets, which are safer but slower."},{"index":2,"anchor":"t2","origin":"page","voice":"user","text":"So when would I choose multiprocessing over multithreading in Python specifically?"},{"index":3,"anchor":"t3","origin":"page","voice":"assistant","text":"In CPython the Global Interpreter Lock (GIL) means only one thread executes Python bytecode at a time, so CPU-bound work doesn't get true parallelism from threads. For CPU-bound tasks — number crunching, image processing — use multiprocessing to sidestep the GIL and use multiple cores. For I/O-bound work — network calls, disk reads — threads (or asyncio) are fine, because the GIL is released during the blocking I/O. Rule of thumb: CPU-bound → processes, I/O-bound → threads or async."},{"index":4,"anchor":"t4","origin":"page","voice":"user","text":"Got it. And how does that relate to asyncio?"},{"index":5,"anchor":"t5","origin":"page","voice":"assistant","text":"asyncio is single-threaded cooperative concurrency: one thread, one event loop, tasks yield control at await points. It shines for high-concurrency I/O — thousands of simultaneous network connections — because there's no thread or process overhead per connection. It does NOT help CPU-bound work, since a long computation blocks the single loop. So the full picture: asyncio for massive I/O concurrency, threads for simpler I/O or blocking libraries, processes for CPU parallelism."}]

Continue

Copy the whole conversation plus a continue-here instruction, ready to paste into another assistant.

Continue the following conversation from where it left off, responding as the assistant.

[User]: What's the difference between a process and a thread?

[Assistant]: A process is an independent program with its own memory space; a thread is a unit of execution that lives inside a process and shares that process's memory with sibling threads. Creating a process is heavier (new address space); creating a thread is lighter (shared address space). Threads communicate through shared memory, which is fast but requires synchronization to avoid races; processes communicate through IPC mechanisms like pipes or sockets, which are safer but slower.

[User]: So when would I choose multiprocessing over multithreading in Python specifically?

[Assistant]: In CPython the Global Interpreter Lock (GIL) means only one thread executes Python bytecode at a time, so CPU-bound work doesn't get true parallelism from threads. For CPU-bound tasks — number crunching, image processing — use multiprocessing to sidestep the GIL and use multiple cores. For I/O-bound work — network calls, disk reads — threads (or asyncio) are fine, because the GIL is released during the blocking I/O. Rule of thumb: CPU-bound → processes, I/O-bound → threads or async.

[User]: Got it. And how does that relate to asyncio?

[Assistant]: asyncio is single-threaded cooperative concurrency: one thread, one event loop, tasks yield control at await points. It shines for high-concurrency I/O — thousands of simultaneous network connections — because there's no thread or process overhead per connection. It does NOT help CPU-bound work, since a long computation blocks the single loop. So the full picture: asyncio for massive I/O concurrency, threads for simpler I/O or blocking libraries, processes for CPU parallelism.

Compare