Epoll vs Kqueue Comparison
Cluster focuses on debates comparing Linux's epoll with BSD's kqueue, Solaris event ports, Windows IOCP, and other I/O event notification mechanisms, discussing their performance, features like batching and event types, and adoption reasons.
Activity Over Time
Top Contributors
Keywords
Sample Comments
What about epoll / kqueue?
Since when did epoll got better than Solaris or Windows alternatives?
Great! I was looking into something like this. I assume ending up with epoll will be better?
Executive summary of the first 53 pages: epoll is great, the other solutions range from not-so-good to terrible.
I'm pretty sure it uses kernel events (epoll, kqueue, /dev/poll) if available.
My favorite comparison is epoll vs kqueue.https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-...https://people.freebsd.org/~jlemon/papers/kqueue.pdf
Was it because epoll vs iocp differences?
The claim is silly and unfounded. If anything, kqueue is the interface that pollutes userspace less. You have a single kevent call that is used both for waiting and registering events represented by (filter, ident) tuples. All of the data related to the event is contained in a struct that’s passed between the kernel and the user. For non-fd events (EVFILT_PROC, EVFILT_TIMER, EVFILT_SIGNAL), it is much more straightforward to use compared to the Linux way where you need to keep track of one more
Solaris has event ports which are equivalent to Windows IOCP. So not all *NIX systems are deficient in that regard :)
What about kqueue or eventports?