Executors, futures & queues
P32.threads-processes.02 · Audience: guest, it-ml, language-pro · Prerequisites: Threads vs processes & the GIL
concurrent.futures is the modern, uniform face of concurrency: submit work,
get a future, and swap ThreadPoolExecutor for ProcessPoolExecutor when the
work turns CPU-bound. This module is the working machinery — all three rungs run
on the kernel so the parallelism is real.
ⓘ Concept: A future is a handle to a result-not-yet
pool.submit(fn, arg) returns a future immediately. Later, future.result() blocks until the value is ready — and re-raises any exception the task hit, so failures surface instead of vanishing. as_completed(futures) yields each future the moment it finishes, so you process results in completion order.Why it matters — Futures decouple 'start the work' from 'collect the result', which is what lets many tasks run at once.
Ask the mentor about this module
Ask a question about this content. The mentor explains and grounds its answer in what you are studying; asking is recorded as a learning signal, not a grade.
Keeping your files on this device
Off by default. The mentor always gets your file; this only decides whether your own copy stays here. Copies live in this browser only - they do not follow you to another device, and clearing site data removes them.
🎓 Practice ladder
3 graded rungs · ~30 minFan work out with a thread pool, cross the process boundary with a picklable
target, then move items through a queue.Queue — all on the kernel.
Rung 1 — fan out with a ThreadPoolExecutor (kernel)
Loading exercise…
Rung 2 — real parallelism with a ProcessPoolExecutor (kernel)
Loading exercise…
Rung 3 — producer/consumer with queue.Queue (kernel)
Loading exercise…
You now have the tools to run work in parallel. The last threads-processes module is about the thing that makes shared state dangerous: what happens when two of those workers touch the same variable at once.
My notes on this module
Loading your notes...
Where next?
Later in Threads & Processes