Initial kqueue experiment

[patricoferris]

I quickly played around with adding kqueue support to iomux, this PR definitely shouldn't be merged but just wanted to make people aware of the experiment :)) (if it is noisy please close).

The current API uses the same buffer that can be shared between poll and ppoll as they're pretty similar. This is nice because set_index and can be used and then either of poll or ppoll can be called. With kqueue you have to maintain some event lists instead and then you either have to make a choice or maintain both bits of state so that this can be preserved. Because I was quickly experimenting I didn't maintain the state and hence I changed some of the tests. This is probably not the way forward.

[haesbaert]

Heya, this is pretty cool ! Not noise at all ! Nice to know it fits kqueue.

My initial plan was to have distinct APIs for ppoll/poll, kqueue, epoll so that we could expose the complete functionality of each. I ended up joining ppoll+poll since I discovered late that OS X didn't have ppoll.

Once these 3 distinct APIs are in place, I'd like to write a generic one that abstracts them, which will invariably have to cut some functionality (kqueue also handle signals and can be used to monitor file changes, which would be cut from the generic API).

Having said that, I'd like the way forward to be us writing our own kqueue bindings, with an API that tries to be 1:1 with the syscall, and then do the same with epoll, and then write a generic API that encompasses them all. So the user can choose to go especific and unportable, or generic and portable.