Python asyncio: How the Event Loop and Coroutines Actually Work

Asyncio is Python's built-in framework for single-threaded cooperative concurrency — one thread, one event loop, many coroutines taking turns. The distinction between coroutine, Task, and Future trips up most people. A coroutine is the object you get when you call an async def function without awaiting: async def foo(): ... ; c = foo() returns a coroutine object, not a result. It's suspended code — it holds its local state but isn't executing. To make it run, you either await it from another coroutine (sequentially) or wrap it in a Task to run concurrently. A Future is a low-level placeholder: "there will be a value here eventually". It has states — pending, finished, cancelled — and a result that's set once. You rarely create Futures in app code; lower-level libraries do. A Task is a subclass of Future that wraps a coroutine and registers it with the event loop so it runs concurrently with other tasks. You create tasks with asyncio.create_task(coro) or implicitly via asyncio.gather(*coros). Gather returns a list of results when all tasks complete. The event loop itself is a scheduler-plus-selector. Every await point either returns immediately if the awaited value is already available, or tells the loop "wake me when this file descriptor / timer / Future is ready". The loop sleeps in an epoll call (Linux) until any registered event fires, then resumes the corresponding coroutine. Because everything is single-threaded, there's no GIL contention between coroutines — they literally take turns. This makes asyncio great for I/O-bound work — thousands of concurrent HTTP requests or database queries — but useless for CPU-bound work, which still blocks the single thread. The canonical mistake is calling a blocking function inside a coroutine (requests.get, time.sleep, a sync DB driver) — it freezes the entire loop and every other coroutine waiting on it. For CPU work, use asyncio.to_thread or run_in_executor to shove the blocking call onto a threadpool.