10 points adletbalzhanov 1 day ago 1 comments
deathanatos 3 minutes ago | parent
> 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.