Mastering High‑Performance Network Frameworks: IO Events, Multiplexing, and the Reactor Pattern

IO Events and IO Multiplexing

Definition of an IO event

In Linux a program exchanges data with external devices (network cards, disks) through its address space. An IO event is a state change that the kernel notifies to the application, typically:

Readable – a new connection arrived or incoming data is available.

Writable – the socket buffer has space and can accept data to be sent.

Exception – error conditions such as connection reset.

IO multiplexing

When thousands of descriptors must be monitored, applications use an IO‑multiplexing API (e.g., epoll, select, poll) to register interest in specific events. The kernel tracks all registered descriptors and wakes the application only when the state of a descriptor changes. Because at any instant only a small fraction of descriptors are active, a single thread can efficiently manage many thousands of connections.

Core Design Elements of a Network Framework

A high‑performance network framework must handle three logical stages:

IO event listening – using an event‑multiplexing mechanism to detect readable, writable, or error events.

Data copying – moving bytes between kernel buffers and user‑space buffers (e.g., read() / write() or recvmsg() / sendmsg()).

Application processing – parsing requests, executing business logic, and constructing responses.

Typical synchronous request flow (single‑threaded example):

Client sends an HTTP request; the NIC generates a readable event.

The kernel notifies the framework’s listen thread.

The listen thread accepts the connection and hands the socket to a handler thread.

The handler thread copies the request data from the kernel buffer to user space.

The application parses the request, performs computation, and builds a response.

The handler thread waits for a writable event.

When writable, the response is copied back to the kernel buffer and transmitted by the NIC.

Thread‑per‑Request vs Event‑Driven Models

Thread‑per‑request

Early designs created one OS thread for each incoming request. While conceptually simple, the model does not scale beyond a few hundred concurrent connections because each thread consumes stack memory and incurs context‑switch overhead.

Event‑driven model

Modern frameworks adopt an event‑driven architecture: a small set of threads runs an event loop that blocks on an IO‑multiplexing call (e.g., epoll_wait) and dispatches callbacks when events occur. This eliminates the one‑thread‑per‑connection bottleneck and allows a single process to handle tens of thousands of connections.

Reactor Pattern Variants

The Reactor pattern separates event demultiplexing from event handling . Common variants are:

Single‑Reactor thread – one thread performs accept, read, write, and dispatch. Simple to implement (e.g., Redis) but limited CPU utilization.

Single‑Reactor + thread pool – the Reactor thread handles only non‑blocking IO; a pool of worker threads processes the business logic. Improves CPU usage while keeping the IO path single‑threaded.

Multiple‑Reactor threads + thread pool – several Reactor threads each own a subset of connections (often partitioned by listening socket or CPU core). This distributes both IO and connection management across cores, achieving higher throughput in production environments.

Synchronous vs Asynchronous IO

Reactor implementations typically use non‑blocking synchronous IO : the application invokes read() / write() on a non‑blocking descriptor; the kernel only signals readiness via the multiplexing API. The data transfer still occurs in the user‑space call. True asynchronous IO (e.g., Linux io_uring , Windows IOCP, Boost.Asio) lets the kernel perform the data movement after the request is submitted, and the application receives a completion notification. Asynchronous IO can exploit DMA and zero‑copy, reducing CPU cycles and latency, but requires kernel support and more complex programming.

Summary

The essential building blocks of high‑performance Linux network frameworks are:

IO event detection via epoll (or equivalent).

Efficient data movement between kernel and user space.

Separation of IO handling from CPU‑bound request processing, realized through the Reactor pattern and optional worker thread pools.

Choice of synchronous non‑blocking IO for simplicity or true asynchronous IO for maximum throughput.