It's slop

But kqueue goes further. It’s not just about file descriptors.

This inversion changes the cost model entirely. Idle connections are cheap. Active connections drive work. Scale becomes feasible.

epoll and kqueue didn’t just improve performance—they changed how systems are designed.

epoll and kqueue are not just APIs. They are acknowledgments

(And that's if you give it cookies. If you don't give the site cookies, it just crashes outright; the content is there, but then some JS wipes it just to tell you "Oh no—this page croaked.")

…and a fair bit of the content is just flagrantly incorrect, but that's par for LLMs. The two biggest things that are just glaringly wrong is that kqueue is a more general interface; most of the alleged "counter-examples" that supposedly make kqueue more general are well-supported¹ by epoll(2).

The article also claims that epoll "won", or something, but never mentions the competing IOCP model, which has seen renewed interest, especially on Linux, in the form of io_uring in recent years. IOCP is pretty fundamentally different, but it has some advantages to (less copying comparing to readiness polling) but some disadvantages (In a naïve implementation, each pending read is holding a buffer, and that can mean a lot of memory use; io_uring has answers to this, but that adds complexity. There's also complexity regarding ownership and cancellation; there are good write-ups about AsyncDrop from the Rust community, but the problem is more general than Rust.)

¹with file I/O being the notable exception. The problem is tractable, in userspace. And … honest nothing stops a readiness model, or even epoll, from working with disk I/O, just, AFAIK, Linux doesn't wanna.