4 ms·

Do you, or anyone else, have any experience from libkqueue? After a quick glance I'm not convinced that it is battle-tested enough, and the Android port is not

Do you, or anyone else, have any experience from libkqueue? After a quick glance I'm not convinced that it is battle-tested enough, and the Android port is not building, Solaris port not really working, etc.

JdeBP 11y ago
kqueue and kevent themselves are available across all of the BSDs; in FreeBSD, OpenBSD, NetBSD, and their various derivatives including Darwin and others. * https://www.freebsd.org/cgi/man.cgi?query=kevent https://www.freebsd.org/cgi/man.cgi?query=kevent * http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/kevent.2 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/... * http://man.netbsd.org/HEAD/usr/share/man/html2/kevent.html http://man.netbsd.org/HEAD/usr/share/man/html2/kevent.html * https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/kevent.2.html https://developer.apple.com/library/mac/documentation/Darwin... This most definitely has been "battle tested" and it long since has provided a means for programs to use a single mechanism to wait for I/O events, directory modifications, signals, child processes, and timers. And it has some interesting abilities, too, such as the ability to keep track of grand-child processes forked off by a child, which one can use to good advantage to handle poorly written daemons that erroneously fork-child-then-exit-parent. libkqueue should not be conflated with this. It provides a workalike API. But there are differences. Some of these are of necessity. Because of the way that Linux signalfds work, for starters, it has been quietly re-specified (the alteration to the wording of the manual page being a subtle one that isn't marked in any way) so that EVFILT_SIGNAL code has to be written differently when using libkqueue on Linux to when using real kevent/kqueue on a BSD. Others are accidents of implementation. One can get spurious wakeups from libkqueue that one doesn't get from real BSD kevent(). Its Linux portion also contains a number of bugs. Internal unexposed file descriptors, for all of the signalfds, timerfds, epolls, inotifys, and whatnot that it opens, are not marked close-on-exec, meaning that there's a significant security concern in any program that uses libkqueue in a privileged process and then forks and executes unprivileged children. The implementation of EVFILT_VNODE/NOTE_WRITE for directories is simply wrong. There are pitfalls when using EVFILT_READ with terminal devices. And its inotify usage doesn't account for the fact that notifications are not always the same number of bytes long. The first two of those bugs are fairly easy to fix. I never got to the bottom of the third. The fourth is more complex, but is addressable I think. The main problem is not fixing these bugs, but getting those fixes available across a multiplicity of Linux distributions, some of which are operating from years-old versions of the library. So even though I wanted (and still want as a matter of fact) to get libkqueue made better, I had to go with dropping libkqueue and implementing my own kqueue()/kevent() workalikes for Linux. * https://www.mail-archive.com/supervision@list.skarnet.org/msg00830.html https://www.mail-archive.com/supervision@list.skarnet.org/ms... * https://www.mail-archive.com/supervision@list.skarnet.org/msg00840.html https://www.mail-archive.com/supervision@list.skarnet.org/ms... * https://www.mail-archive.com/supervision@list.skarnet.org/msg01043.html https://www.mail-archive.com/supervision@list.skarnet.org/ms...

JdeBP 11y ago

kqueue and kevent themselves are available across all of the BSDs; in FreeBSD, OpenBSD, NetBSD, and their various derivatives including Darwin and others. * https://www.freebsd.org/cgi/man.cgi?query=kevent https://www.freebsd.org/cgi/man.cgi?query=kevent * http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/kevent.2 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/... * http://man.netbsd.org/HEAD/usr/share/man/html2/kevent.html http://man.netbsd.org/HEAD/usr/share/man/html2/kevent.html * https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man2/kevent.2.html https://developer.apple.com/library/mac/documentation/Darwin... This most definitely has been "battle tested" and it long since has provided a means for programs to use a single mechanism to wait for I/O events, directory modifications, signals, child processes, and timers. And it has some interesting abilities, too, such as the ability to keep track of grand-child processes forked off by a child, which one can use to good advantage to handle poorly written daemons that erroneously fork-child-then-exit-parent. libkqueue should not be conflated with this. It provides a workalike API. But there are differences. Some of these are of necessity. Because of the way that Linux signalfds work, for starters, it has been quietly re-specified (the alteration to the wording of the manual page being a subtle one that isn't marked in any way) so that EVFILT_SIGNAL code has to be written differently when using libkqueue on Linux to when using real kevent/kqueue on a BSD. Others are accidents of implementation. One can get spurious wakeups from libkqueue that one doesn't get from real BSD kevent(). Its Linux portion also contains a number of bugs. Internal unexposed file descriptors, for all of the signalfds, timerfds, epolls, inotifys, and whatnot that it opens, are not marked close-on-exec, meaning that there's a significant security concern in any program that uses libkqueue in a privileged process and then forks and executes unprivileged children. The implementation of EVFILT_VNODE/NOTE_WRITE for directories is simply wrong. There are pitfalls when using EVFILT_READ with terminal devices. And its inotify usage doesn't account for the fact that notifications are not always the same number of bytes long. The first two of those bugs are fairly easy to fix. I never got to the bottom of the third. The fourth is more complex, but is addressable I think. The main problem is not fixing these bugs, but getting those fixes available across a multiplicity of Linux distributions, some of which are operating from years-old versions of the library. So even though I wanted (and still want as a matter of fact) to get libkqueue made better, I had to go with dropping libkqueue and implementing my own kqueue()/kevent() workalikes for Linux. * https://www.mail-archive.com/supervision@list.skarnet.org/msg00830.html https://www.mail-archive.com/supervision@list.skarnet.org/ms... * https://www.mail-archive.com/supervision@list.skarnet.org/msg00840.html https://www.mail-archive.com/supervision@list.skarnet.org/ms... * https://www.mail-archive.com/supervision@list.skarnet.org/msg01043.html https://www.mail-archive.com/supervision@list.skarnet.org/ms...