Yeah, the article really doesn't make a case as much as assert it.
One way to think about this is whether all these non-file fds are useful for a variety of generic operations, or whether they're only used for epoll and one-off system calls or ioctls specific to that type of fd. If it's the latter, it seems hard to believe that there actually is some kind of composability advantage.
So, what can you do with them?
1. You can use these fds with poll()/select(), not just epoll. That's not a big deal, since nobody really should be using either of them. But it does also mean that you should ideally be able to use them with any future event notification syscalls as well. And the invention of new mechanisms is not hypothetical, since Linux added io_uring. I'd be curious to know how well io_uring supports arbitrary fd types, and whether they got that support "for free" or if io_uring needs to be extended for every new fd type.
2. You can typically read() structured data from those fds describing the specific event. With kqueue all that data would need to be passed through struct kevent, which needs to be fixed size and generic enough to be shared between all the different event types.
3. You can pass individual fds between processes, either via UDS or fork(). I expect you would not be able to do that for individual kqueue filters.
4. You can close() the fd to release the underlying kernel resource. This doesn't seem interesting, just listing it for completeness.
So there's probably enough smoke there that one could at least argue the case. It's too bad the author didn't.
> ...nobody really should be using either of them.
What's wrong with poll(), at least for smaller values of nfds? And what should one use instead when writing POSIX-compatible portable code, where epoll() and kqueue() don't exist?
Fun fact, on openbsd(at least, I don't know about freebsd) select and poll were reworked to use kqueue internally.
The thread is an interesting read as it sounds like the naive approach has negative performance implications, knowing openbsd I suspect the main motivation was to reduce maintenance burden, that is, make it easier to reason about the internals of event driven mechanisms by only having one such system to worry about.
One way to think about this is whether all these non-file fds are useful for a variety of generic operations, or whether they're only used for epoll and one-off system calls or ioctls specific to that type of fd. If it's the latter, it seems hard to believe that there actually is some kind of composability advantage.
So, what can you do with them?
1. You can use these fds with poll()/select(), not just epoll. That's not a big deal, since nobody really should be using either of them. But it does also mean that you should ideally be able to use them with any future event notification syscalls as well. And the invention of new mechanisms is not hypothetical, since Linux added io_uring. I'd be curious to know how well io_uring supports arbitrary fd types, and whether they got that support "for free" or if io_uring needs to be extended for every new fd type.
2. You can typically read() structured data from those fds describing the specific event. With kqueue all that data would need to be passed through struct kevent, which needs to be fixed size and generic enough to be shared between all the different event types.
3. You can pass individual fds between processes, either via UDS or fork(). I expect you would not be able to do that for individual kqueue filters.
4. You can close() the fd to release the underlying kernel resource. This doesn't seem interesting, just listing it for completeness.
So there's probably enough smoke there that one could at least argue the case. It's too bad the author didn't.