Python — GIL, async & when not to use it
Core details
CPython executes bytecode with a Global Interpreter Lock: one thread runs Python bytecode at a time per process.
| Workload | Typical approach |
|---|---|
| I/O-bound | asyncio or threads often fine; many waits release GIL |
| CPU-bound | multiprocessing, native extensions, or other language—threads won’t parallelize CPU-heavy Python |
async/await: cooperative multitasking; blocking calls in async def (sync DB client) stalls the loop—use async drivers or thread pool offload.
Understanding
GIL is CPython-specific; other implementations differ. Interview honesty: “For heavy numeric work I’d reach for vectorized libs or process pool.”
Senior understanding
Django / Flask sync vs ASGI stack; deployment (gunicorn workers vs uvicorn). Memory: generational GC; reference cycles need weakref awareness in extensions.
Diagram
thread A ──┐
thread B ──┼──► GIL ──► one bytecode runner at a time
thread C ──┘ (I/O wait may drop GIL)See also
Last updated on
Spotted something unclear or wrong on this page?