Non-Blocking I/O

The core principle where an I/O request returns immediately without waiting for the operation to complete. The application is notified via a callback, event, or future when data is ready. This decouples request initiation from completion, preventing a slow network call from blocking the entire thread.

• Mechanism: System calls like epoll (Linux), kqueue (BSD/macOS), or IOCP (Windows) monitor multiple file descriptors.
• Contrast: Blocking I/O suspends the thread until the kernel copies data to user space, wasting CPU cycles.

The architectural pattern that powers non-blocking runtimes. A single-threaded event loop continuously polls for I/O readiness events from the OS kernel. When an event is detected, it dispatches the corresponding handler or callback.

• Demultiplexing: The synchronous event demultiplexer (e.g., select, epoll) blocks the event loop only until new events arrive.
• Concurrency Model: Achieves concurrency through interleaved task execution, not parallel threads. A long-running CPU task can still starve the event loop.

A critical control mechanism in non-blocking systems where a fast producer can overwhelm a slow consumer. Non-blocking I/O frameworks implement reactive pull-based backpressure to dynamically adjust the flow of data.

• Implementation: The consumer signals its capacity (e.g., requesting n items) to the producer. This propagates upstream to the source.
• Goal: Prevents unbounded memory buffer growth and OutOfMemoryError crashes under load, ensuring system stability without blocking threads.

An optimization technique that eliminates redundant data copying between kernel space and user space during I/O operations. Non-blocking servers use system calls like sendfile() or splice() to transfer data directly from a file descriptor to a socket.

• Process: Data moves from the disk cache to the socket buffer via the DMA (Direct Memory Access) engine, bypassing the application's memory entirely.
• Impact: Dramatically reduces CPU utilization and memory bandwidth consumption, enabling wire-speed throughput for static file serving.

A programming model that makes asynchronous code look synchronous. Fibers (or virtual threads) are user-mode scheduled execution contexts that can be suspended and resumed at specific suspension points, typically I/O calls.

• Mechanism: When a fiber hits a non-blocking call, the underlying scheduler parks it and switches to another ready fiber on the same OS thread.
• Benefit: Avoids callback hell and complex promise chaining, allowing developers to write linear, readable code while retaining the scalability of non-blocking I/O.

An extreme form of non-blocking I/O that circumvents the OS kernel's TCP/IP stack entirely. Libraries like DPDK or io_uring map network interface card (NIC) buffers directly into user space for direct hardware access.

• io_uring: A modern Linux interface using two lock-free ring buffers (submission and completion queue) for efficient, batched system calls.
• Use Case: Essential for ultra-low-latency systems (e.g., high-frequency trading) where even the kernel's context switch overhead is too high.

The core programming construct that continuously monitors and dispatches events or callbacks in a non-blocking system. A single-threaded event loop can manage thousands of concurrent connections by iterating through ready I/O operations rather than waiting on each one. Node.js and Nginx are built entirely around this model. The loop operates in distinct phases: timers, pending callbacks, idle/prepare, poll, check, and close callbacks.

An asynchronous pattern where I/O operations are initiated and their completion is handled by a separate handler. Unlike the Reactor pattern, the Proactor delegates actual I/O work to the operating system kernel and receives completion notifications. This is the model used by I/O Completion Ports (IOCP) on Windows and the io_uring subsystem on Linux. It enables true asynchronous I/O where the application never blocks on data transfer.

Lightweight, user-space concurrency primitives that allow writing asynchronous code in a synchronous style. Coroutines suspend execution at I/O boundaries and yield control back to an event loop, resuming when data is available. Languages like Kotlin (suspend functions), Go (goroutines), and Python (async/await) use this model. Unlike OS threads, thousands of coroutines can exist with minimal memory overhead, typically measured in kilobytes per coroutine.

Operating system kernel interfaces that enable efficient I/O multiplexing. epoll (Linux) and kqueue (BSD/macOS) notify applications when file descriptors become ready for I/O, avoiding busy-waiting. io_uring (Linux 5.1+) goes further by using shared memory ring buffers for submission and completion queues, enabling true asynchronous I/O with zero system call overhead in the fast path. These are the low-level primitives that power every high-performance non-blocking server.