Generated by GPT-5-mini| kqueue | |
|---|---|
| Name | kqueue |
| Developed by | FreeBSD Project |
| Initial release | 2000 |
| Operating system | FreeBSD, OpenBSD, NetBSD, DragonFly BSD, macOS |
| License | BSD license |
| Website | https://www.freebsd.org |
kqueue
kqueue is an event notification interface introduced in FreeBSD that provides scalable event monitoring for file descriptors, signals, timers, and other kernel-level sources. It was created to improve I/O multiplexing efficiency compared to traditional interfaces and has influenced event systems in macOS, NetBSD, and other operating systems. Designers and implementers associated with FreeBSD Project and contributors from Berkeley Software Distribution and related communities integrated kqueue into several networking and server projects such as nginx, OpenSSH, and Postfix. The mechanism interacts with kernel facilities and user-space runtimes used by projects including libevent, libuv, Node.js, Tokio (software), and nginx to build high-performance servers and asynchronous frameworks.
kqueue was developed in response to scalability limitations observed with interfaces like select (Unix), poll (Unix), and early epoll prototypes in the late 1990s and early 2000s. Work on kqueue occurred within FreeBSD development branches influenced by networking research at institutions such as University of California, Berkeley and commercial users like Yahoo! and Netcraft that needed high-concurrency network services. Key contributors included developers from FreeBSD Project and collaborators who later impacted macOS via Darwin (operating system). kqueue’s concepts were driven by real-world deployments in server software stacks like Apache HTTP Server, nginx, and mail transfer agents such as qmail and Postfix.
kqueue centers on a kernel-managed event queue and a minimal syscall interface that lets user-space register event filters and retrieve pending events efficiently. The design separates event registration from event retrieval, enabling batching and reducing system call overhead—a principle adopted by frameworks like libevent and libuv. kqueue supports synchronous and asynchronous patterns used by runtimes such as Node.js and Tokio (software), and it integrates with process-level facilities present in POSIX-derived systems including BSD (operating system). The model uses filters and kevent structures to represent interest and changes, enabling integration with kernel subsystems like the socket (networking), pipe (Unix), signal (software), and timer implementations used in macOS and FreeBSD.
kqueue provides multiple filter types to monitor diverse kernel events: file descriptor readability/writability through socket and file filters used by nginx, OpenSSH, and Dovecot; signal delivery monitored similarly to implementations in Postfix and sshd; process lifecycle and child status events as used by systemd-like supervisors and service managers; and user-defined events for bespoke servers such as those built with Twisted (software) or Boost.Asio. Timer filters offer high-resolution timing suitable for applications like Redis and Memcached extensions. The extensible filter model allowed projects like libevent and libuv to abstract platform differences for cross-platform software such as node.js and Python (programming language)’s asynchronous libraries.
The kqueue API exposes operations to create a queue, add or remove filters via kevent structures, and fetch pending events. User-space libraries—libevent, libuv, nghttp2 integrations, and language bindings in Python (programming language), Ruby (programming language), Go (programming language), and Rust (programming language) ecosystems—wrap the raw syscalls to offer higher-level abstractions used by nginx, HAProxy, Lighttpd, and application servers. Typical usage patterns include edge-trigger-like behavior for network servers, timer-driven reservoirs for event loops in Node.js and Tor (anonymity network), and signal integration for graceful shutdowns in OpenSSH and Postfix. Implementers often combine kqueue with non-blocking I/O and scatter/gather APIs exemplified by readv/writev and zero-copy techniques appearing in FreeBSD kernel optimizations.
kqueue was designed to reduce the per-event overhead seen in select (Unix) and poll (Unix), enabling servers to manage tens or hundreds of thousands of concurrent connections as demonstrated by benchmarks involving nginx, Lighttpd, HAProxy, and custom workloads used by companies like Facebook and Google in research contexts. Its event batching reduces context switches and syscall frequency, a benefit also sought by epoll on Linux and IOCP on Windows. Scalability considerations include kernel memory pressure, event fanout, and fairness strategies that have been studied in academic work from USENIX conferences and industrial performance reports by vendors such as Apple Inc. and the FreeBSD Foundation. Profiling tools from DTrace and perf (Linux) analogues have been used to tune kqueue-driven applications.
kqueue originated in FreeBSD and was later ported to macOS through Darwin (operating system), and to other BSDs including OpenBSD, NetBSD, and DragonFly BSD. Third-party adaptations and emulations exist in cross-platform libraries like libevent and libuv to provide uniform APIs on Linux, Windows, and mobile platforms. Projects such as FreeRDP and Qt (software) include conditional support to leverage kqueue where available. Proprietary and research operating systems have studied kqueue semantics when designing their own event mechanisms, and vendor-specific kernel tuning in Apple Inc.’s macOS kernels reflects ongoing maintenance and optimization.
kqueue is often compared to epoll on Linux, IOCP on Windows, and select (Unix)/poll (Unix) primitives. While epoll and IOCP target similar scalability goals, kqueue provides built-in filters for signals, timers, and process events that epoll lacks natively, leading projects like libevent to use kqueue where available for richer semantics. Cross-platform frameworks such as libuv and Boost.Asio abstract these differences for applications like Node.js, nginx, and Redis. Trade-offs between these mechanisms involve API ergonomics, platform portability, edge vs level-trigger semantics documented by authors from FreeBSD Project and discussions at conferences like USENIX and ACM SIGCOMM.
Category:BSD programming interfaces