Improve accuracy of timeout/interval

[ioquatix]

In the past, when implementing things like this, I've added a factor to the interval to ensure that it doesn't over-shoot.

I'm not sure where is the right place to implement this, but essentially it would be nice if the selector kept track of how much time it was asked to wait, and how much time it actually waited. Then, adjust the future call by a factor to get closer to this goal. Interestingly enough, it can be as low as 0.8 or so.

I'm not proposing we do this, but really just starting a discussion surrounding the best way to handle this. Perhaps libev exposes this somehow?

[tarcieri]

I regret using a float for timeout intervals. Unfortunately this seems par for the course for Ruby. Using an integer number of e.g. microseconds would probably be the best way to improve the accuracy.

As far as some sort of automatic jitter/drift adjustment for timeouts goes, I don't think that's going to work. Environmental noise (task switching/scheduling, GC, etc) is nondeterministic, so any inaccuracy you're able to measure in one invocation may be due to causes which have nothing to do with subsequent invocations.

[ioquatix]

It's interesting, but simply multiplying interval by 0.8 ensures a significantly improved accuracy in the async gem. It's compounding over each iteration of the event loop, so it's probably feasible to increase the accuracy by quite a bit. But, I accept it may not be the right place in nio4r.

[ioquatix]

What was wrong using a float? It's at least as accurate as integral milliseconds.

[tarcieri]

What could go wrong when 0.1 + 0.2 == 0.30000000000000004?

[ioquatix]

If you use a pentium from the 90s, your CPU could fault and self destruct the universe.

[ioquatix]

Revisiting this, it is out of scope. Closing.