Waiting for Input — poll and select

An interactive program spends nearly all of its life doing nothing, and doing nothing well is a genuine engineering problem. Your editor's main loop wants to say: "wake me when the user types, but no later than 100 ms from now, because I might also have a resize to handle or a status message to expire." A plain blocking read can't express "no later than"; a VMIN=0 polling read can, but only by burning CPU in a spin loop or by committing the whole program to VTIME's tenth-of-a-second granularity on one fd.

The general answer — the one every event loop from vim to nginx to your terminal emulator is built on — is readiness notification: ask the kernel to block for you, on a set of fds, with a deadline.

poll()

#include <poll.h>

struct pollfd {
    int   fd;       /* which descriptor                   */
    short events;   /* what you care about (POLLIN, ...)  */
    short revents;  /* what actually happened (kernel fills) */
};

int poll(struct pollfd *fds, nfds_t nfds, int timeout_ms);

You hand poll an array of fds and what you're waiting for (POLLIN — readable; POLLOUT — writable without blocking), plus a timeout in milliseconds (-1 = forever, 0 = just check). It returns:

• > 0: that many entries have nonzero revents. Check each.
• 0: the timeout expired; nothing happened.
• -1: error — and yes, EINTR again: a signal (SIGWINCH!) woke the process. For us that's a feature, but the caller must decide whether to retry, and with how much of the deadline left.

The crucial semantic: poll tells you a read won't block, not how much data there is. The contract is "one read will return something" — maybe 1 byte. Readiness, then short read, then loop: the two lessons compose.

POLLHUP (hang-up: the other end closed) and POLLERR can appear in revents unrequested. Treat them as "readable" — the read will return 0 or an error, which is exactly the news you need.

select(), for the record

select(2) is poll's older sibling: same idea, clunkier interface (fd bitmasks you rebuild every call, a struct timeval the kernel may scribble on, and a hard FD_SETSIZE ceiling of 1024 fds). You'll read it in older code — kilo's tutorial era used it — but there is no reason to write new select code. For thousands of fds there's epoll (Linux) / kqueue (BSD); a terminal watching one or two fds needs none of that.

Deadlines that survive EINTR

There's a subtle bug lurking in the obvious retry loop:

while (poll(&p, 1, timeout_ms) < 0 && errno == EINTR)
    ;  /* BUG: restarts the FULL timeout after every signal */

If signals arrive steadily (a user leaning on the resize handle), the deadline recedes forever. Correct code computes the deadline once, against a monotonic clock, and re-arms poll with whatever remains:

struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
long deadline_ms = ts.tv_sec * 1000 + ts.tv_nsec / 1000000 + timeout_ms;
/* after EINTR: remaining = deadline_ms - now_ms; if <= 0, timed out */

CLOCK_MONOTONIC, not time() or CLOCK_REALTIME: wall clocks jump (NTP, DST, a sysadmin); the monotonic clock only marches forward.