The return of kevent?
Posted May 17, 2007 17:09 UTC (Thu) by slamb
In reply to: The return of kevent?
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.
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
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
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.
to post comments)