Fix time precision problems on Windows

[ecdavis]

The precision of the time.time() function on Windows is too low for Pants to accurately execute cycle functions within 0.01 seconds of when they should be executed. This may affect other platforms too, but it does not affect OS X or Linux.

One possible solution is to use the clock() function to provide extra precision. This could be done for Windows only, or for all platforms. Further experimentation is required.

[AphonicChaos]

Conversation on stackoverflow [1] suggests that using time on *Nix platforms is not a good idea. You could probably just do something like this:

if platform.system() == 'Windows':
    from time import clock as time
else:
    from time import time

If both are needed, you could simply set a module global instead.

[ecdavis]

Thanks for your input, @aspidites. Unfortunately this is not just a problem with time() on Windows, but also sleep(). I've made a few changes which have certainly improved timer precision on the platform, but have not completely resolved this issue. In practical terms, I think the precision is now good enough for most people and is similar enough to other platforms to be consistent. I am closing this issue for the moment as I don't believe there is much more that can be done.

[ecdavis]

Some further information for (my) future reference:

• Windows' time.time() is not particularly precise, so we use time.clock() on Windows to keep track of elapsed time.
• Windows' time.sleep() is precise down to 2d.p., meaning that if you tell Windows to sleep for 0.015 seconds it will sleep for either 0.01 or 0.02 seconds (in fact, it will alternate between the two if you repeatedly call sleep())
• These two issues combined with the inherent problems with floating point numbers mean that Pants will sometimes sleep for slightly too little time, meaning that the next time poll() is called it is too early to call the timer function.
• The timer is "missed" and has to wait until the next poll() call to execute. In the case of cycles, this ends up delaying the whole cycle.

Current solutions are the use of clock and the minimum sleep time of 0.01 seconds. These workarounds have drastically improved timer precision but have not completely resolved the problem. I've also messed with the unit tests so that they pass consistently. I realise that's naughty but until we decide to fix this properly (if we ever do), I don't want tests failing intermittently.

Real solutions to this problem will involve changing the way cycles work - perhaps by having them "catch up" and execute twice when they miss an opportunity that could delay the entire cycle.