3 ms·

I feel this should really mention the epoll pitfalls (cf. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/ https://idea.popcount.org/2017-

I feel this should really mention the epoll pitfalls (cf. https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/ https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-... ) - though "fundamentally broken" is excessive hyperbole. Also this specific article is kinda hazy on pointing out epoll's improvements over previous APIs. One half is that event subscriptions are registered/submitted for a period longer than one syscall (which the article kinda-sorta says.) But the other half is that you also have an opaque field (mostly used as pointer) that the kernel returns back to you on event notifications, which removes an extra level of lookup in userspace. And lastly, FreeBSD has in the meantime acquired epoll support, and Linux is moving to the next-yet-again replacement in io_uring (which calling an epoll/poll replacement is an insult, it does much more.)

another2another 3y ago
>and Linux is moving to the next-yet-again replacement in io_uring (which calling an epoll/poll replacement is an insult, it does much more.) Yes, at least this time they support true async disk IO, which epoll doesn't.
o11c 3y ago
Almost nobody actually uses epoll at that kind of scale though. Almost everybody is just fine with `accept` from just one thread. and `SO_REUSEPORT` is safe if you're using a fixed thread pool; it only fails if you use a variable-size thread pool or if you're using multiple processes and one dies (though frankly, if a process dies, you're going to lose something anyway). The "but what if I `fork` and `close`" problem is purely theoretical I'm pretty sure.