The return of kevent? [LWN.net]

The return of kevent?

Posted May 17, 2007 13:52 UTC (Thu) by pphaneuf (subscriber, #23480)
In reply to: The return of kevent? by slamb
Parent article: The return of kevent?

Good old select/poll did have ridiculous overheads at low loads, with large numbers of clients, but yeah, epoll is more than good enough.

As you mention on your sigsafe main API documentation, if you're using an event loop and non-blocking I/O already, you can do the pipe trick very easily, so in the context of this event delivery mechanism, that's kind of the obvious answer, rather than starting to wrap all the "slow" system call. So while there are some things that could be done to make it even better, I'm not worrying.

You find that there's that much usefulness to the kqueue extra information? For most of those (in any case, those things you can also watch with epoll, there's some interesting "extra" stuff like watching processes in kqueue), you get the same information with an extra system call (the read() or accept() that gives you EAGAIN, for example).

I kind of use it in the more basic way, behind an abstraction for it, epoll and select, most of the time. The thing is, if I had that extra information in my abstraction, then I'd have to have some special "I don't know" value for select/epoll, test for that, slightly different behaviour between epoll and kqueue, etc... So I just don't really find it worth the trouble, at the moment. But I'm open to the idea that I might be missing something...

(Log in to post comments)

The return of kevent?

Posted May 17, 2007 17:09 UTC (Thu) by slamb (guest, #1070) [Link]

Good old select/poll did have ridiculous overheads at low loads, with large numbers of clients, but yeah, epoll is more than good enough.

Yeah, I'm just comparing kevent to Linux's best existing mechanism - epoll_wait(). As far as I'm concerned, select()/poll() is a straw man. O(n) with number of watched descriptors is ridiculous.

As you mention on your sigsafe main API documentation, if you're using an event loop and non-blocking I/O already, you can do the pipe trick very easily, so in the context of this event delivery mechanism, that's kind of the obvious answer, rather than starting to wrap all the "slow" system call.

Right, but Ulrich wants to implement thread cancellation. Even that is possible in a way that doesn't lose edge events. Not that I think it's worthwhile to do, as thread cancellation is hopelessly messed up for other reasons. But ncm tells me that the C++ people are looking at doing things right with "thread interruption", though, and an approach like sigsafe might be useful there.

You find that there's that much usefulness to the kqueue extra information?

I confess that I haven't actually taken advantage of any of it, but I think there's potential, especially as more event types are added. And here he is actually talking about returning information right away vs. making another system call per event, so this syscall overhead reduction argument makes more sense than removing the actual polling call.

The return of kevent?

Posted May 17, 2007 20:30 UTC (Thu) by slamb (guest, #1070) [Link]

The thing is, if I had that extra information in my abstraction, then I'd have to have some special "I don't know" value for select/epoll, test for that, slightly different behaviour between epoll and kqueue, etc... So I just don't really find it worth the trouble, at the moment. But I'm open to the idea that I might be missing something...

One thing is that not everyone cares about writing portable code. I used to always write everything in this way (don't use fancy features or don't depend on them), but a few things started to change my mind. One of them was reading this story. Another was starting to work on a BSD-based proprietary system. We have the make world style - a single source tree, no collection of RPMs with tarballs and patches. We can add libraries, daemons, and kernel extensions that the rest of the system depends on. We don't use autoconf-based fallback code or lowest-common denominator abstraction layers. We've given up on the idea of sending most of our changes upstream, so we do what works for us. It can be liberating to say "screw portability/ compatibility". It's much easier to do on our system where you can make a single changeset that modifies everything you need and be certain one piece will never run on a real system without the other.

Now I'm ready to take the same attitude to other code that I write. Portability isn't a hard requirement; it's something to be kept as long as it doesn't hold me back too much. Code doesn't run on Python 2.2? Who cares?!? I run mostly CentOS 5, which has Python 2.4, so I'll take advantage of the newer language features. Code doesn't run without epoll_wait() or kevent()? Who cares?!? I use systems with modern kernel interfaces. Code doesn't run without a Linux-only kernel interface? Maybe I'll add it or something equivalent to BSD if I want to run it there.