| |||||||||||||
|
| |||||||||||||
Choosing between portability and innovationChoosing between portability and innovationPosted Mar 9, 2011 14:48 UTC (Wed) by mheily (guest, #27123)In reply to: Choosing between portability and innovation by nevyn Parent article: Choosing between portability and innovation Actually, you don't need to redesign your kernel to implement the kqueue API on Linux. The libkqueue project provides a userspace wrapper library that translates each kevent() call into the equivalent epoll/inotify/timerfd/signalfd/etc call for Linux. On Solaris, it uses the event port framework. On Windows, it will use the WaitForMultipleObjects() function. (Disclaimer: I am the main author of libkqueue)
(Log in to post comments)
Choosing between portability and innovation Posted Mar 9, 2011 20:52 UTC (Wed) by nevyn (subscriber, #33129) [Link]
My biggest concern with doing something like that would be how efficient it is compared to using the native interface (and why I said you'd need to redesign the kernel, so that it could be implemented efficiently), the only benchmark you have is vs. poll() (and uses ab) ... which is pretty sad.
epoll <=> kqueue is probably the best case test too, to be convincing you'd want something that benchmarked EVFILT_VNODE/SIGNAL/TIMER at least. To be really convincing you'd want PROC/USER/AIO and play with the EV_* flags.
|
|
||||||||||||