What does it actually mean for a thread to "block" on an operation, and why is one blocked thread far more damaging inside an event-driven runtime than inside a server that dedicates a thread to each request?

## What blocking is A thread is *blocked* when it cannot make progress and is waiting for something external. Usually the operating system parks it: the thread leaves the CPU, is placed on a wait queue, and becomes runnable again when the event it waits for occurs. Sometimes it spins instead, burning CPU while polling. In both cases one property holds — **the thread is unavailable for other work, and everything it owns stays reserved**: its stack, its entry in whatever pool handed it out, and any locks it holds. The common blocking operations are worth naming, because people only remember the first one: - Network reads and writes on a blocking handle. - Regular-file reads and writes, including implicit ones like loading a class, reading a config file, or touching a memory-mapped page that is not resident. - Acquiring a contended lock or semaphore. - Waiting on a queue, a latch, a future, or a child process. - Name resolution — often forgotten, frequently slow, frequently synchronous even in "async" libraries. - Long CPU-bound computation. It does not park the thread, but it is *indistinguishable from blocking* to everyone else waiting for that thread. Cryptography, compression, big JSON serialisation and regular-expression backtracking all qualify. ## Why the same call has two very different costs The damage from blocking equals *how many logical tasks that thread was carrying*. **Thread-per-request.** Each request owns a thread for its lifetime. Blocking is the normal state — a pool of 200 threads exists on the assumption most are parked waiting on I/O. One slow dependency delays the requests that touch it; unrelated requests keep flowing on other threads. The system is wasteful in memory but *contained* in blast radius. It fails only when the pool is exhausted, which is a resource limit you can watch, size and alarm on. **Event-driven.** A few threads run an endless loop: take the next ready event, run a short handler, take the next. Every connection is multiplexed over those threads, so a thread is not *a* request — it is *all of them, in turn*. Handlers are expected to be short and to yield at every wait point, returning the thread to the loop. If a handler blocks for 200 ms: - Every event already queued for that loop waits 200 ms longer. - Nothing is preempted out — the loop is a cooperative scheduler; it cannot take the thread back. - The symptom is latency on endpoints that have nothing to do with the slow call, which is deeply confusing during an incident. - With N loop threads, N concurrent blocking calls stop the service completely, and N is typically the core count, not a big number. The same reasoning applies to lightweight-thread runtimes, one level down: a task that blocks in a way the runtime cannot intercept *pins its carrier thread*, and there are only a few carriers. ## The rule and its consequence The rule is simple: **never block, and never run long, on a thread that carries other people's work.** The consequence is that async systems need a place to put unavoidable blocking work — a separate, bounded pool of ordinary threads whose only job is to absorb it, so the event loops stay free. Async code then waits for that pool's result *asynchronously*, which keeps the loop yielding. ## Blocking is not the same as being slow An asynchronous call to a slow service still takes a long time; the difference is that no thread is held while it waits. Latency is a property of the dependency; thread occupancy is a property of your code. Async I/O does not make anything faster — it makes waiting free in thread terms, so a fixed number of threads can hold a much larger number of in-flight operations. If a candidate says "we went async and it got faster", the honest version is "we stopped running out of threads". ## How to notice Two signals catch this reliably. First, **event-loop (or scheduler) latency**: the delay between an event becoming ready and its handler starting. It rises for *all* work when any handler blocks, which distinguishes hidden blocking from a genuinely slow dependency. Second, **blocking-call detectors**: instrumentation or agents that flag known blocking operations executing on a loop thread. Both belong in a service that mixes blocking libraries with async plumbing.