an event-notification interface

Imagine you are a receptionist watching twenty phones. You cannot pick up one and wait on it while the others ring unanswered. What you want is a single board that lights up to say 'phones 3 and 17 need you now,' so you handle exactly those and ignore the silent ones. An event-notification interface is that board for I/O: a system call through which a program watches many file descriptors at once and is told which ones are ready to read or write, so it can serve only those.

Concretely, these interfaces let one thread monitor many sources. With select or poll, the program hands the OS a list of file descriptors it cares about and a request like 'wake me when any of these is readable.' The call blocks until at least one is ready, then returns the set that is ready; the program services those and asks again. The classic versions (select, poll) re-scan the whole list every call, which gets slow with thousands of descriptors. So Linux added epoll (and BSD added kqueue), where you register interest once and the kernel keeps a running list, returning only the descriptors that actually became ready — turning an O(n) scan into something closer to O(number of ready events). These are the readiness building blocks underneath event-driven and asynchronous I/O.

Why it matters: this is how a single-threaded server handles tens of thousands of connections without spawning a thread per connection (which would waste memory and scheduling effort). It is the heart of the event loop in web servers, databases, and async runtimes. One honest distinction to keep straight: select/poll/epoll tell you a descriptor is ready (you must still issue the read or write yourself), whereas a true asynchronous I/O interface performs the operation and tells you when it is done — readiness notification versus completion notification are related but not the same.