NO_EPOLL=1 kills CPU, busywaits.

[srh]

To reproduce.

1. Build rethinkdb with make NO_EPOLL=1.
2. Run htop or some other CPU monitor in another terminal.
3. Run ./build/debug-noepoll/rethinkdb

Put a debugf in front of the poll(2) call in arch/runtime/event_queue/poll.cc and you'll see that it spins around the loop, busywaiting, with many calls per millisecond while the server should be idling. Compare that with epoll, where you'll see one call per 5 milliseconds (because of the timerfd timer).

The OS X port (#5) is waiting on this.

[coffeemug]

You should take this issue. I believe this is a regression -- we had a similar issue before which was fixed. I don't remember what the cause was, but I believe it was pretty simple.

Another possibility is this -- NO_EPOLL might have been only meant for builds with LEGACY_LINUX turned on. Try turning on both NO_EPOLL and LEGACY_LINUX -- do you experience the same problem? If that turns out to be the case, we should probably fix NO_EPOLL to work even in the absence of LEGACY_LINUX, because that's a sensible thing to do.

[srh]

It is confirmed that we don't get the problem with LEGACY_LINUX=1. That option disables epoll compilation. This will help narrowing down the problem.

[srh]

It turns out that the problem is not particularly deep. We just pass in 0 as the timeout parameter to poll, when passing -1 is what would give us infinite timeout. When under LEGACY_LINUX, we used ppoll, for which an infinite timeout is passed correctly.

[srh]

This has been fixed and pushed.