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.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds