4 ms·

Kqueue doesn't support submission to begin with, no kernel<->ringbuffer support which is the point of this article, I'm not sure if it can be nested, and the cr

by _wmd 8y ago

Kqueue doesn't support submission to begin with, no kernel<->ringbuffer support which is the point of this article, I'm not sure if it can be nested, and the cross section of features it supports differs fairly wildly from e.g. epoll. Meanwhile I agree, it's a lovely interface, and vastly less system call-heavy than epoll

wahern 8y ago
> Kqueue doesn't support submission What do you mean by this? If you mean that kqueue doesn't support adding or modifying events simultaneous with querying, then as the OP said it does. > no kernel<->ringbuffer support which is the point of this article That's an implementation detail. Indeed, a 2007 Linux kqueue patch used ring buffers. See https://lwn.net/Articles/233462/ https://lwn.net/Articles/233462/ > I'm not sure if it can be nested Can you poll on kqueue descriptors recursively? (That is, install a notification event for kqueue descriptor C with kqueue B, which in turn is installed with kqueue A, such that readiness for kqueue C bubbles up to kqueue A) Yes, you can. Same thing with Solaris Port descriptors. > cross section of features it supports differs fairly wildly from e.g. epoll. kqueue is an API framework for exposing pollable notification events (i.e. event filters in kqueue parlance). If the semantics of an event type is different, just use different identifiers. Different BSDs support different identifiers (e.g. MacOS supports polling on a Mach Port with EVFILT_MACHPORT) or different flags (notes in kqueue parlance) to control semantics of pre-existing identifiers. Expecting Linux to adopt kqueue is unreasonable, especially at this point when Linux has reproduced much (but hardly all) common kqueue event filters. What remains irksome, however, is how epoll+friends have ignored the design decisions and real-world experience of kqueue. Most annoying IMO is the behavior of epoll on fork. This despite the fact that kqueue was both ridiculously well documented and mature by the time epoll came out, not to mention the simple fact that the semantics are just atrocious for anyone familiar with Unix programming.[1] [1] It seems obvious to me that this poor behavior of epoll was an implementation short-cut. Other poor behaviors were premature optimizations. All turned out, IMHO, to have been entirely unnecessary. Tragic considering how Linux once championed the idea that most of the time (if not all of the time) you can make the convenient or most sensible semantics at least as performant as designs that sacrifice ergonomic, composable semantics at the alter of optimization (and in particular optimizations with very specific, very niche use cases in mind). This notion is still preached in the Linux world but not practiced as much, a consequence of corporate influence. (You can see the same thing in FreeBSD, though to a lesser extent. FreeBSD is better at polishing their turds.)
- _wmd 8y ago
  > What do you mean by this? OP's comment is n the context of an article describing extensions to AIO to support polling, one of the benefits of that mechanism is a single call can submit new IO operations simultaneous to registering readiness notifications. AFAIK neither epoll nor kqueue support that Thanks for weighing in, plenty to digest here Re: epoll-on-fork, do you mean the behaviour where it associates with the wrong kernel object? I knew about that one, although fork sounds curious, but I think you're probably just referring to the trouble fd leaks can cause due to the former issue

by _wmd 8y ago

wahern 8y ago

> Kqueue doesn't support submission What do you mean by this? If you mean that kqueue doesn't support adding or modifying events simultaneous with querying, then as the OP said it does. > no kernel<->ringbuffer support which is the point of this article That's an implementation detail. Indeed, a 2007 Linux kqueue patch used ring buffers. See https://lwn.net/Articles/233462/ https://lwn.net/Articles/233462/ > I'm not sure if it can be nested Can you poll on kqueue descriptors recursively? (That is, install a notification event for kqueue descriptor C with kqueue B, which in turn is installed with kqueue A, such that readiness for kqueue C bubbles up to kqueue A) Yes, you can. Same thing with Solaris Port descriptors. > cross section of features it supports differs fairly wildly from e.g. epoll. kqueue is an API framework for exposing pollable notification events (i.e. event filters in kqueue parlance). If the semantics of an event type is different, just use different identifiers. Different BSDs support different identifiers (e.g. MacOS supports polling on a Mach Port with EVFILT_MACHPORT) or different flags (notes in kqueue parlance) to control semantics of pre-existing identifiers. Expecting Linux to adopt kqueue is unreasonable, especially at this point when Linux has reproduced much (but hardly all) common kqueue event filters. What remains irksome, however, is how epoll+friends have ignored the design decisions and real-world experience of kqueue. Most annoying IMO is the behavior of epoll on fork. This despite the fact that kqueue was both ridiculously well documented and mature by the time epoll came out, not to mention the simple fact that the semantics are just atrocious for anyone familiar with Unix programming.[1] [1] It seems obvious to me that this poor behavior of epoll was an implementation short-cut. Other poor behaviors were premature optimizations. All turned out, IMHO, to have been entirely unnecessary. Tragic considering how Linux once championed the idea that most of the time (if not all of the time) you can make the convenient or most sensible semantics at least as performant as designs that sacrifice ergonomic, composable semantics at the alter of optimization (and in particular optimizations with very specific, very niche use cases in mind). This notion is still preached in the Linux world but not practiced as much, a consequence of corporate influence. (You can see the same thing in FreeBSD, though to a lesser extent. FreeBSD is better at polishing their turds.)

_wmd 8y ago
> What do you mean by this? OP's comment is n the context of an article describing extensions to AIO to support polling, one of the benefits of that mechanism is a single call can submit new IO operations simultaneous to registering readiness notifications. AFAIK neither epoll nor kqueue support that Thanks for weighing in, plenty to digest here Re: epoll-on-fork, do you mean the behaviour where it associates with the wrong kernel object? I knew about that one, although fork sounds curious, but I think you're probably just referring to the trouble fd leaks can cause due to the former issue