how do I use kevent and select?

kevent's file descriptor returned by kqueue() can be used as input to select() or kevent().

1. What are the advantages of using this method?

2. Suppose kevent is waiting on a list of descriptors by using kevent() and there are some acti开发者_StackOverflowvities on that list. Will kevent's file descriptor be set, readable by select() or kevent()?

---

For OSX/BSD - kevent is the bsd/osx scalability solution that is on par with the windows I/O Completion Port model, or the linux epoll model.

After getting used to it, I think I like it better than the other models for simplicity and flexibility; although the API is a little rough around the edges.

The primary advantage of this over select is scale. select() needs a lot of tricks and/or hacks to setup and tear down efficiently when used with a large number of file handles, and the number of file handles is often capped. poll() removes the limit on number of file handles, but still has the setup/teardown issues; and is not available natively in OSX.

I want to make an argument for improved context switching. This is true in windows IOCP, especially if using the new Vista APIs and the OS thread pooling. I believe it is true on OSX, but I would be hard pressed to give absolute examples.

For flexibility, it's nice that handles can be easily registered and removed from kqueues. But that's a convenience. The real nice thing with kevent is that it can associate with things that are not file handles. I prefer this to the epoll solution where everything has to be a file handle - yes, it's the unix mantra - but still some things have had to be hacked in to work with epoll.

kevents non-requirement on file descriptors lets you specifically monitor file reads, writes, attribute changes, deletion, renames. Process exits, forks, signals. events on a mach port (not on bsd). Timers, and user events.

It's really convenient to be able to handle all these kinds of events from a single API running on multiple threads using callback handlers.

So that was a very long winded answer to (1).

As for (2); I'm not sure I understand. I believe a single 'trigger activity' will cause kevent and select to trip should that file descriptor be pending in both.

One warning that is become less and less relevant. kevent on OSX 10.5.x is less than reliable. Some of the expected events just aren't supported and there are some bugs, or perhaps errata since the documentation of behaviour is vague. Such as... closing a socket/descriptor while waiting for it on a kevent may not trigger the kevent in some cases. From what I've seen kevent is OSX' underpinning technology for Grand Central Dispatch and it's really been improved in 10.6 and newer.