8 ms·

Yes I would say kqueue, the interface, is superior to epoll. Kqueue allows one to batch modify watcher states and to retrieve watcher states in a single system

by asomiv 15y ago

Yes I would say kqueue, the interface, is superior to epoll. Kqueue allows one to batch modify watcher states and to retrieve watcher states in a single system call. With epoll, you have to call a system call for every modification. Kqueue also allows one to watch for things like filesystem changes and process state changes, epoll is limited to socket/pipe I/O only. It's a shame that Linux doesn't support kqueue. But as awesome as kqueue is, OS X apparently broke it: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AND_DARWIN_BUGS http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AN...

gorset 15y ago
I fully agree that kqueue is awesome, but what specifically is broken on OSX? I've used in extensively on that platform, and haven't run into any showstoppers.
- asomiv 15y ago
  You can't poll on TTYs for example. I remember this bug from 2004 and apparently they still haven't fixed it.
  - gorset 15y ago
    Yeah, the lack of support for TTYs can be annoying when writing a terminal application (a workaround for some cases is to use pipes), but it hardly qualifies as a significant problem for writing network applications. Here's a more interesting bug in OSX: kqueue will sometimes return the wrong number for the listen backlog for a socket under high load.
Flow 15y ago
IIRC, kqueue can be told to read the whole http-request before letting client know there's data to read.
- rdtsc 15y ago
  How does it work? Do users provide a buffer and the kernel fills the buffer with data and notifies the user when ready? That is more akin to AIO Linux system, then? Otherwise, epoll/poll/select just notifies users when data is available but the actual copy is done by the user. Surprisingly this can make a huge difference when streaming large amounts of data. http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-an... We have argued here before and I have gotten downvoted into oblivion for being pedantic and distinguishing between asynchronous IO and non-blocking IO but it looks like that extra user-space memcpy can make a huge difference.
  - Flow 15y ago
    I can't find anything about this now, just spent a good 20 minutes searching for it. I guess keywords kqueue, buffer request http are too generic in some sense. :-/ Anyway, the idea was to avoid context switches by waiting/parsing in kernel-side till there was enough data for the client to do something else that just another gimme_more_data()-call back to the kernel. It could even be applied to other methods than kqueue, so perhaps I remember a bit wrong that this was just for kqueues.
- gorset 15y ago
  That's actually accept_filter(9). The man page for freebsd has a interesting info: The accept filter concept was pioneered by David Filo at Yahoo! and refined to be a loadable module system by Alfred Perlstein. The closest you can get by using kqueue is to set a low water mark, so that a read event is only returned when there's enough data ready.
  - Flow 15y ago
    Ah, that's it! Thanks for finding it.

by asomiv 15y ago

gorset 15y ago

I fully agree that kqueue is awesome, but what specifically is broken on OSX? I've used in extensively on that platform, and haven't run into any showstoppers.

asomiv 15y ago
You can't poll on TTYs for example. I remember this bug from 2004 and apparently they still haven't fixed it.
- gorset 15y ago
  Yeah, the lack of support for TTYs can be annoying when writing a terminal application (a workaround for some cases is to use pipes), but it hardly qualifies as a significant problem for writing network applications. Here's a more interesting bug in OSX: kqueue will sometimes return the wrong number for the listen backlog for a socket under high load.

Flow 15y ago

IIRC, kqueue can be told to read the whole http-request before letting client know there's data to read.

rdtsc 15y ago
How does it work? Do users provide a buffer and the kernel fills the buffer with data and notifies the user when ready? That is more akin to AIO Linux system, then? Otherwise, epoll/poll/select just notifies users when data is available but the actual copy is done by the user. Surprisingly this can make a huge difference when streaming large amounts of data. http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-an... We have argued here before and I have gotten downvoted into oblivion for being pedantic and distinguishing between asynchronous IO and non-blocking IO but it looks like that extra user-space memcpy can make a huge difference.
- Flow 15y ago
  I can't find anything about this now, just spent a good 20 minutes searching for it. I guess keywords kqueue, buffer request http are too generic in some sense. :-/ Anyway, the idea was to avoid context switches by waiting/parsing in kernel-side till there was enough data for the client to do something else that just another gimme_more_data()-call back to the kernel. It could even be applied to other methods than kqueue, so perhaps I remember a bit wrong that this was just for kqueues.
gorset 15y ago
That's actually accept_filter(9). The man page for freebsd has a interesting info: The accept filter concept was pioneered by David Filo at Yahoo! and refined to be a loadable module system by Alfred Perlstein. The closest you can get by using kqueue is to set a low water mark, so that a read event is only returned when there's enough data ready.
- Flow 15y ago
  Ah, that's it! Thanks for finding it.