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