Glossary term

Event Loop

Engineering definition of an event loop covering run-to-completion dispatch, nonblocking I/O, handler budgets, queue delay, blocking hazards and validation.

Branch: Computer Engineering
Glossary type: concept
Content: Glossary term
Updated: Jun 26, 2026
Revision: v1.0.0 · reviewed

Definition

concept

An event loop is a dispatch mechanism that repeatedly waits for events, selects ready work and runs handlers, often on a single thread with run-to-completion semantics.

Event loops appear in operating systems, network services, user-interface runtimes, embedded gateways, message brokers and telemetry processors when many asynchronous events must be coordinated without assigning a blocking thread to each event. A useful design states the event sources, dispatch order, handler budget, nonblocking I/O rule, timer behavior, queue policy, offload path, cancellation rule, lag metric and validation evidence.

An event loop is a dispatch mechanism that repeatedly waits for events, selects ready work and runs handlers, often on a single thread with run-to-completion semantics. It is a concurrency model, not merely a performance metric.

Event loops appear in operating systems, network services, user-interface runtimes, embedded gateways, message brokers, telemetry processors and device-control software. They simplify shared state because one loop can serialize mutations, but one slow handler can delay unrelated timers, callbacks, cancellation and health checks.

Dispatch Cycle

Let ready event queue length be:

Q_e

and let one selected handler be:

H_i

A simple loop repeats:

\text{wait}\rightarrow\text{select event}\rightarrow\text{run handler}\rightarrow\text{repeat}

Under run-to-completion semantics, a handler runs until it returns control to the loop. No other handler on that loop can run during that interval.

Handler Budget

Let event arrival rate be:

\lambda_e

and average handler cost be:

C_h

Approximate loop utilization is:

\rho_e=\lambda_e C_h

As:

\rho_e\to 1

callback delay and event-loop lag grow quickly. The loop may still be single-threaded and correct, but it is no longer timely.

Nonblocking Contract

An event-loop handler should not perform blocking I/O, long CPU work, unbounded allocation, synchronous logging or waits on unrelated locks unless that delay is explicitly budgeted. Work that may block should usually be moved to a worker, a message queue, an async operation or a bounded offload path.

If blocking time inside a handler is:

B_h

then every ready event behind that handler inherits at least that delay:

T_{delay}\geq B_h

This coupling is the core risk of a single dispatch thread.

When It Fits

An event loop fits workloads with many concurrent connections, short handlers, clear state ownership and operations that can be expressed as nonblocking callbacks or promises. It is weaker for long CPU work, blocking device calls, unpredictable allocation, heavy compression, large parsing jobs or code that must wait synchronously for another subsystem. Those tasks need a bounded worker path or a different concurrency model.

Queue and Timer Effects

Timers on an event loop are not guaranteed to run at the exact scheduled instant. They run after the loop becomes free and after earlier ready callbacks have executed.

Let expected timer time be:

T_{exp}

and observed callback time be:

T_{obs}

then event-loop lag is:

T_{lag}=T_{obs}-T_{exp}

The event-loop page defines the architecture. The lag metric measures how late that architecture is under load.

Offload Boundary

Offloading work to a thread pool can protect the event loop, but it introduces another capacity boundary. If the pool saturates, completions may be delayed and callbacks can still pile up on the loop. The design should state what work remains on the loop, what is offloaded, how cancellation crosses the boundary and how backpressure reaches producers.

For a callback deadline:

D_e

with queue delay:

W_q

and handler execution:

C_h

the deadline margin is:

M_D=D_e-W_q-C_h

A negative margin means the loop is no longer meeting its timing contract.

Failure Modes

Common failure modes include handler blocking, unbounded callback queues, retry storms scheduled on the same loop, garbage-collection pauses, synchronous logging, large JSON parsing, slow DNS or storage calls, cancellation callbacks delayed behind ordinary work, health checks delayed by overload and watchdog resets caused by missed loop service.

An event loop can also starve low-priority work if high-priority events continuously requeue themselves. Average request latency can hide that failure unless wait time is measured by work class.

Worked Check

Suppose an event loop receives:

\lambda_e=4000\ \text{callbacks/s}

and average handler cost is:

C_h=180\ \mu\text{s}

Then:

\rho_e=4000(180\times10^{-6})=0.72

If synchronous logging adds:

100\ \mu\text{s}

per callback, the new handler cost is:

C_h=280\ \mu\text{s}

and:

\rho_e=4000(280\times10^{-6})=1.12

The loop is overloaded before considering bursts. The fix is not to tune timers; it is to remove blocking work, shed load, offload safely or reduce event arrival rate.

Validation Evidence

Useful evidence includes event-loop lag probes, callback duration distributions, queue depth, timer delay, blocked-stack samples, CPU profiles, garbage-collection pause correlation, thread-pool completion delay, retry counts, cancellation delay, watchdog service interval and p99 latency under burst traffic.

A strong event-loop review states which handlers are allowed to run on the loop, their maximum cost, what happens when the queue grows and which metric proves that timers, cancellation and health checks remain timely.

REF

Disciplines