To Poll or Not to Poll -- That is the Question

Reduced polling does not always lead to CPU nirvana. In embedded or driver environments, it can be more efficient to poll devices than to wait for interrupts. The overhead of interrupts can be very high. For an interesting discussion of this tradeoff in FreeBSD, see [15].

For the rest of us, shielded from the vagaries of interrupts by high-level operating systems, response from external devices is already handled by the operating system, and we have no choice but to use the APIs designed to abstract such event-driven architectures. In these cases, using an API like select, and letting it block until input arrives, will be the most efficient solution, allowing the operating system to perform the details of efficient device handling, whether that be polling interrupts or otherwise. Your latency mileage will vary of course, but it should be close to the optimum provided by your platform.