select(2)

select(2)
Name	select
Syscall	select(2)
Standard	POSIX.1-2001
Availability	Unix-like

select(2)

select(2) is a UNIX/POSIX system call and library interface for monitoring multiple file descriptors to see if any of them is ready for I/O, enabling event-driven and multiplexed I/O in processes such as servers and interactive applications. It is widely implemented across Unix, Linux, FreeBSD, NetBSD, OpenBSD, and influenced designs in Windows API, Plan 9 from Bell Labs, and networking stacks used by Apache HTTP Server, nginx, PostgreSQL, and OpenSSH. select remains relevant alongside newer interfaces like poll(2), epoll, kqueue, and io_uring for compatibility and portability.

Overview

select(2) provides a mechanism for a process to inspect sets of file descriptors for readiness to perform reading, writing, or exceptional condition handling without blocking on a single descriptor. It integrates with I/O subsystems used by Berkeley Software Distribution, System V, GNU C Library, musl libc, and event-driven frameworks such as libevent, libuv, Node.js, Twisted, and nginx modules. Typical applications include network daemons like Sendmail, Postfix, OpenSMTPD, graphical toolkits derived from X Window System, and terminal multiplexers like tmux and screen.

POSIX/System Call Interface

The POSIX-specified prototype for select appears in headers from POSIX.1-2001 and POSIX.1-2008 and is usually provided by unistd.h and sys/select.h in implementations from The Open Group and vendor distributions such as Red Hat Enterprise Linux, Debian, Ubuntu, and FreeBSD. The interface uses bitsets to represent file descriptor sets and relies on operating system kernel support for readiness notification used by networking stacks like TCP/IP and socket APIs standardized in Berkeley sockets and influenced by standards committees such as IEEE and IETF.

Parameters and Usage

select(2) accepts a highest-numbered file descriptor plus one, and three file descriptor sets for read, write, and exceptional conditions, together with an optional timeout specified via a timeval structure. Implementations in glibc and musl expect fd_set types manipulated with macros like FD_ZERO, FD_SET, FD_CLR, and FD_ISSET, which are used in applications such as inetd, xinetd, vsftpd, OpenSSH's multiplexing, and event loops in GNOME and KDE programs. Portability issues arise with descriptor limits like FD_SETSIZE, encountered on platforms maintained by Apple Inc., Solaris (operating system), AIX, and embedded systems supported by BusyBox.

Return Values and Error Handling

On success, select returns the number of ready file descriptors; a return of zero indicates a timeout expired. On error, it returns -1 and sets errno to values such as EINTR, EBADF, EINVAL, or ENOMEM. Error handling patterns are visible in server codebases like nginx, database servers like MySQL, MariaDB, and PostgreSQL where loops check for EINTR (interrupts from signals such as those raised by SIGINT or SIGTERM) and routines interact with facilities like poll(2), epoll_wait, or kqueue to recover or escalate.

Examples and Code Snippets

Common idioms use FD_SET and timeval to wait for readability on sockets created with socket() and accepted via accept() as in examples drawn from Beej's Guide to Network Programming, UNIX Network Programming by Rich Stevens, and tutorials used by MIT, Stanford University, and other teaching institutions. Real-world snippets appear in projects like OpenSSL where select coordinates I/O on encrypted sockets, and in proxy servers such as HAProxy which compare select-based loops with advanced mechanisms. Typical C snippets illustrate initializing fd_set, setting a timeout, calling select, and then using FD_ISSET to dispatch handlers for descriptors connected to services such as HTTP/1.1 and SMTP.

Limitations and Alternatives

select(2) scales poorly for very large descriptor counts due to O(n) scans and copying of fd_set bitmaps on each call and is constrained by FD_SETSIZE on many libc implementations, issues addressed by alternatives: poll(2), Linux-specific epoll, BSD-specific kqueue, and newer asynchronous I/O frameworks like io_uring and POSIX AIO. High-performance servers such as nginx, lighttpd, and libuv-based applications often prefer these alternatives for lower latency, reduced syscall overhead, and better edge-triggered semantics.

Historical Context and Implementations

select originated in early BSD networking code at University of California, Berkeley and was formalized through BSD releases and later standardized by IEEE POSIX and The Open Group. Implementations evolved across Sun Microsystems's Solaris, IBM's AIX, and open-source kernels from Linus Torvalds's Linux and the FreeBSD Project. Its design influenced event APIs in Windows NT that yielded IO Completion Ports and shaped multiplexing in systems like Plan 9 and research projects at institutions such as Bell Labs and MIT Lincoln Laboratory.

Security and Performance Considerations

When used to manage network sockets, select-based loops must validate descriptors to avoid races and descriptor reuse vulnerabilities that can affect daemons like sshd or mail servers maintained by OpenBSD and Debian teams. Performance tuning involves reducing fd_set copying, limiting FD_SETSIZE, using nonblocking sockets and careful timeout choices, and considering alternatives like epoll or kqueue for high-concurrency services such as Facebook-scale web frontends, content delivery networks run by Akamai, or large-scale databases such as Cassandra and HBase.

Category:Unix programming