What does Python’s GIL change about threads?
Separate CPU-bound work from waiting on I/O, and name the tool you would use for each.
Points worth saying
- The GIL lets one thread run Python bytecode at a time in a process.
- Threads still help when the work is waiting on the network or disk.
- CPU-bound parallelism needs processes, or code that releases the GIL.
A full answer
CPython’s global interpreter lock means two threads in one process do not run Python bytecode at the same instant. A CPU-heavy loop split across threads will not use two cores. You added scheduling cost and kept one core busy.
Threads are still the right tool for I/O. While one thread waits on a socket or a file, it releases the GIL and another thread can run. A crawler or a service that calls several APIs can overlap that waiting with threads or with asyncio.
For CPU-bound work, use separate processes so each one has its own interpreter and its own GIL. The cost is that you pass data by message, not by sharing a list. Native extensions that release the GIL can also run in parallel, which is why numeric libraries are not stuck on one core.
Say the constraint before you pick the tool. If the profile shows waiting, threads or async are enough. If the profile shows Python bytecode on one core, processes are the honest answer. The GIL is not a reason to avoid threads for I/O.
Mark your progress
Create a practice profile to mark this question.