🔄Python asyncio

Why asyncio exists

Picture a web service that, per request, waits on a database, then an upstream API, then writes a response. It spends almost all of its wall-clock time waiting — the CPU is idle, parked on a socket. The classic way to handle many such requests at once is one OS thread per connection. That works until it doesn't: each thread carries a stack measured in megabytes, and the kernel pays a context-switch cost every time it swaps them. At ten thousand mostly-idle connections — the famous C10k problem — the machine spends more effort scheduling threads than doing work.

asyncio makes a different bet: if the work is waiting, you don't need a thread for each wait. One thread runs an event loop. Each in-flight operation is a cheap coroutine — a heap object, not an OS stack. When a coroutine would block on I/O, it registers interest with the loop's selector and yields; the loop moves on to whatever is ready now. Concurrency scales to tens of thousands of connections on a single core, because idle connections cost almost nothing.

So the scope is narrow and worth stating out loud in an interview: asyncio buys concurrency, not parallelism. It shines when you have many operations that spend their time waiting on the network or disk. It does nothing for a workload that keeps a CPU busy — that needs multiple processes (see the comparison below).

Mental model in 60 seconds

The event loop is a single thread running one job: keep a queue of ready-to-run tasks, take one, run it until it awaits something not yet ready, then set it aside and take the next. When an awaited operation completes — a timer fires, a socket becomes readable — its task goes back on the ready queue. Repeat until nothing is left to do.

Three properties fall out of this, and they explain almost everything about how async code behaves:

• Single-threaded. Your coroutine code never runs concurrently with itself. Within one uninterrupted run there are no data races on ordinary variables — a relief compared to threads.
• Cooperative, not preemptive. The loop can only switch tasks at an await. Between two awaits your code runs to completion, uninterrupted. That is the double edge of asyncio: you always know exactly where a switch can happen, but a task that never awaits (a busy CPU loop) never yields and starves the loop.
• One loop, started with asyncio.run. It creates the loop, drives your top-level coroutine to completion, and closes the loop. One event loop per thread.

import asyncio

async def main():
    await asyncio.gather(worker("a"), worker("b"))

asyncio.run(main())   # create the loop, run main() to completion, close the loop

Coroutines & await

An async def defines a coroutine function. The thing to internalize: calling it does not run it. It returns a coroutine object — inert — exactly the way calling a generator function returns a generator without executing the body. Nothing happens until you await it (or schedule it as a Task, or hand it to asyncio.run).

async def fetch(url): ...

fetch(url)         # returns a coroutine object — the body never runs (RuntimeWarning)
await fetch(url)   # now it actually runs

await X does two things at once. It drives X toward its result, and — the important part — if X is not ready, it suspends the current coroutine and hands control back to the event loop. await is the only place a coroutine can pause, and you can only write it inside an async def. What you can await is any awaitable — a coroutine, a Task, or a Future.

This is why await asyncio.sleep(1) and time.sleep(1) are worlds apart. asyncio.sleep suspends the coroutine for a second and lets the loop run everyone else; time.sleep blocks the whole thread — and with it the loop and every other task. Hold that thought; it becomes the cardinal rule below.

async def main():
    save(record)         # BUG: coroutine created, never awaited → the save never happens
    await save(record)   # fix

Coroutine vs Task vs Future

Interviewers love this one because the three are easy to conflate and the difference is where concurrency actually comes from. Three related things:

• Coroutine — the recipe. What async def returns. Inert until driven. Awaiting a coroutine directly runs it inline, in the current task: sequential.
• Task — a coroutine the loop runs concurrently. asyncio.create_task(coro()) wraps the coroutine, schedules it on the loop, and returns immediately with a handle. The task advances whenever the current task awaits. You await the handle later to collect its result.
• Future — a result that will exist later. A low-level placeholder with a state (pending → done) and eventually a value or an exception. Libraries hand you Futures to bridge callback-style code; you rarely build one yourself. Crucially, Task is a subclass of Future — a Future whose value is produced by running a coroutine.

The operational punchline — worth being able to write on a whiteboard:

import asyncio

async def slow(n):
    await asyncio.sleep(n)
    return n

# Sequential — await one, then the next. total ≈ 1 + 2 = 3s
a = await slow(1)
b = await slow(2)

# Concurrent — schedule both, then await. total ≈ max(1, 2) = 2s
ta = asyncio.create_task(slow(1))   # both are running now
tb = asyncio.create_task(slow(2))
a, b = await ta, await tb        # they progressed while we awaited

Same coroutines, very different timing. Awaiting a coroutine is not the same as scheduling a Task. create_task is the verb that makes work overlap — remember it and the rest of concurrency is ergonomics.

Running things concurrently

You rarely hand-roll create_task pairs. Two ergonomic tools cover almost everything.

asyncio.gather — fan out, collect in order

Schedules every coroutine, waits for all of them, and returns their results positionally.

results = await asyncio.gather(fetch(a), fetch(b), fetch(c))   # [ra, rb, rc]

Watch the failure semantics — a favorite follow-up. By default, if one coroutine raises, gather propagates that first exception to the caller but the others keep running (and if you never await them, they can leak). Pass return_exceptions=True and it instead returns exceptions as results rather than raising — convenient, but it silently turns failures into return values, so you must inspect them.

asyncio.TaskGroup — the modern default (3.11+)

A context manager that owns its child tasks. This is the recommended way to run concurrent work today.

async with asyncio.TaskGroup() as tg:
    t1 = tg.create_task(fetch(a))
    t2 = tg.create_task(fetch(b))
# the block exits only after both finish;
# if either raises, the other is cancelled and errors surface together
results = t1.result(), t2.result()

It is structured: control does not leave the async with block until every child is done, and if one fails, the siblings are cancelled and the errors are raised together as an ExceptionGroup. No orphaned tasks, no swallowed errors — the two things gather makes easy to get wrong.

_background = set()

def spawn(coro):
    t = asyncio.create_task(coro)
    _background.add(t)                       # keep a strong ref...
    t.add_done_callback(_background.discard)   # ...drop it when finished
    return t

Structured concurrency & cancellation

Structured concurrency means a task's lifetime is bounded by a scope, so you can't leak tasks and errors can't disappear. TaskGroup is asyncio's implementation of the idea (borrowed from Trio's nurseries). Cancellation is the machinery that makes it work.

Cancellation is cooperative too

task.cancel() does not kill anything on the spot. It schedules a CancelledError to be raised inside the coroutine at its next await. The coroutine may catch it to clean up — but should re-raise, or cancellation silently fails to happen.

try:
    await do_work()
except asyncio.CancelledError:
    await rollback()   # clean up...
    raise              # ...then let the cancellation propagate

Put cleanup in finally. And note the type hierarchy is deliberate: CancelledError derives from BaseException, not Exception, precisely so a broad except Exception: doesn't accidentally eat a cancellation.

Timeouts

asyncio.timeout() (3.11+) is a context manager that cancels whatever runs inside it once the clock runs out — built directly on cancellation.

async with asyncio.timeout(5):
    await slow_operation()          # raises TimeoutError if it runs > 5s

# older, still fine — wraps a single coroutine:
await asyncio.wait_for(slow_operation(), timeout=5)

Both work by cancelling the inner operation, so the same rules apply: clean up in finally, don't swallow the CancelledError. When you have an operation that must not be interrupted by an outer cancel — a commit, say — wrap it in asyncio.shield(...), sparingly.

Never block the event loop

If you remember one operational fact about asyncio, make it this — and expect an interviewer to push on it. There is one thread. Any code that runs without awaiting holds the loop hostage; nothing else — not another request, not a health-check heartbeat — makes progress until it returns. Two ways to commit this sin:

1. CPU-bound work — a tight loop, hashing, parsing a huge payload, resizing an image. It never awaits, so nothing else runs until it finishes.
2. Synchronous I/O — time.sleep, requests.get, a blocking database driver, a plain file read. These block the OS thread, and the loop is on that thread.

The symptom is distinctive: latency spikes across unrelated requests, all stalling in lockstep, because they share the one thread that is stuck.

The fix is to get the blocking work off the loop thread.

# Blocking I/O call → run it on a worker thread, await the result
row = await asyncio.to_thread(blocking_db_query, sql)        # 3.9+

# CPU-bound work → a process pool, which sidesteps the GIL
loop = asyncio.get_running_loop()
result = await loop.run_in_executor(process_pool, heavy_cpu, data)

asyncio.to_thread hands the call to a ThreadPoolExecutor and gives you back an awaitable; the loop keeps serving other tasks while the worker thread sits in the blocking call.

Coordinating tasks

Even on one thread you need coordination, for a subtle reason: state can change across an await. Between awaits your code is atomic, but at an await another task may run and mutate shared state. That is where async races live — a check-then-act split by an await.

# NOT atomic: the await lets another task run between check and act
async def get(key):
    if key not in cache:              # check
        cache[key] = await load(key)   # two tasks can both miss and both load
    return cache[key]

Guard the critical section with an asyncio.Lock so the check-then-act runs to completion for one task at a time:

lock = asyncio.Lock()

async def get(key):
    async with lock:                 # serialize the whole check-then-act
        if key not in cache:
            cache[key] = await load(key)
        return cache[key]

Bounded concurrency with Semaphore

Fanning out ten thousand requests at once will exhaust sockets or file descriptors, or get you rate-limited. A semaphore caps how many run at a time while still letting you schedule them all.

sem = asyncio.Semaphore(20)          # at most 20 in flight

async def fetch(url):
    async with sem:                  # waits here if 20 are already out
        return await client.get(url)

await asyncio.gather(*(fetch(u) for u in urls))   # 10k scheduled, 20 at a time

Producer / consumer with Queue

An asyncio.Queue decouples producers from consumers, and a maxsize gives you backpressure for free — put suspends when the queue is full, throttling producers to the consumers' pace.

q = asyncio.Queue(maxsize=100)        # bounded → backpressure

async def producer():
    for item in source:
        await q.put(item)             # suspends when full

async def consumer():
    while True:
        item = await q.get()
        await handle(item)
        q.task_done()

asyncio vs threads vs processes

The architecture question, and the one where a crisp answer signals seniority. Choose by what the work is waiting on.

The decision, in one breath: waiting on the network or disk with an async library available → asyncio. Waiting on a blocking library you can't replace → threads (or asyncio plus to_thread). Crunching numbers → processes. And they compose — a common production shape is an asyncio server that offloads occasional CPU chunks to a ProcessPoolExecutor and stubborn blocking calls to a thread pool.

Interview gotchas

A tight checklist of the mistakes and "gotcha" questions that come up most. Being able to name and fix each is most of what "knows asyncio" means at this level.

• Forgot the await. A coroutine created but never awaited never runs — Python only whispers a RuntimeWarning.
• Blocking the loop. time.sleep, requests, or a CPU loop freezes every task. Offload with to_thread / a process pool, or use an async-native library.
• Sequential when you meant concurrent. await a(); await b() runs one after the other. Overlap them with gather, a TaskGroup, or explicit create_task.
• Orphaned tasks. The result of create_task must be kept alive, or the task can be GC'd and silently dropped. Hold the handle or use a TaskGroup.
• Swallowing CancelledError. It's a BaseException, so except Exception misses it — but catching it explicitly and not re-raising breaks cancellation.
• Trusting gather(return_exceptions=True). It converts failures into ordinary return values; if you don't inspect them, errors vanish.
• Expecting parallelism. asyncio is one thread — it will not speed up CPU-bound code. That's what processes are for.
• Mixing sync and async. You can't await in a plain function, and calling an async def without awaiting (or a running loop) just makes an inert coroutine.
• Racing across an await. Check-then-act split by an await isn't atomic; another task can slip in. Guard it with a Lock.
• Cross-thread misuse. asyncio primitives aren't thread-safe; bridge threads and the loop with run_coroutine_threadsafe / call_soon_threadsafe.

Further reading

• CPython asyncio docs — start with Developing with asyncio and the Coroutines & Tasks page (TaskGroup, timeouts, cancellation). The authoritative reference for the current API.
• PEPs that shaped it — 3156 (asyncio), 492 (async/await), 525 (async generators), 654 (exception groups / except*).
• Structured concurrency — Nathaniel J. Smith's Notes on structured concurrency and the Trio docs, the design that TaskGroup borrows from.
• Talks — David Beazley's Build Your Own Async and Die Threads build the event loop from scratch — the fastest way to make the model click.
• Ecosystem — uvloop (a faster libuv-backed loop), AnyIO (a structured-concurrency layer that runs on asyncio or Trio), and async-native drivers like asyncpg and httpx.