Challenge 3: Why epoll Makes Tracking Thousands of Connections Cheap — Solution Walkthrough

What a naive approach would require:

Without epoll, tracking thousands of connections for new activity
would require either continuously checking each connection one at a
time in a loop (wasting CPU cycles checking connections that have no
new data), or dedicating a separate thread to each connection so it
can block and wait on that one connection specifically — the
thread-per-connection model this chapter's own predecessor course
(Web Servers Fundamentals) contrasted against Nginx's own approach.
Both options scale poorly as the number of connections grows into the
thousands.

What epoll actually does instead:

epoll lets a single Nginx worker register all of its open connections
with the Linux kernel once, then simply ask the kernel "which of these
connections actually has new data ready right now?" The kernel itself
tracks connection state efficiently and only reports back the small
subset that actually needs attention, rather than the worker having to
check every connection individually or dedicate a thread to each one.

Why this makes the difference:

Because the kernel — not the Nginx worker itself — is doing the
expensive part of watching thousands of idle connections, one worker
process can efficiently juggle many more connections than a
one-thread-per-connection model ever could, without a proportional
increase in CPU work as the number of idle connections grows. This is
the concrete technical mechanism underneath what Web Servers
Fundamentals described only conceptually as "non-blocking I/O."

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that epoll is understood as a genuine mechanism
— the kernel doing the expensive per-connection watching so the
worker doesn't have to — rather than just a name to associate loosely
with "Nginx is efficient."