Higher-precision sleep on Windows

[clarfonthey]

Right now, the sleep method uses Sleep on Windows, which only has millisecond precision. Even though the function explicitly allows rounding up to higher ticks, it would be nice to allow higher-precision timers.

After a quick search I was able to find that the SetWaitableTimer function (used in this gist) supports much higher precision timing, so, this is theoretically possible. I'm not particularly good at Windows programming, though, so, I shouldn't be doing this myself.

[jrmuizel]

I don't believe this will actually let you sleep for periods less than 1ms. See: https://stackoverflow.com/questions/7827062/is-there-a-windows-equivalent-of-nanosleep?rq=1 and https://stackoverflow.com/questions/85122/how-to-make-thread-sleep-less-than-a-millisecond-on-windows

[dtolnay]

This does not affect the API of std::thread::sleep at all right, just the implementation on Windows? If so, I would welcome a PR!

[haesy]

On my current Windows 10 machine, std::thread::sleep has a minimum sleep time of roughly 15 ms. Calling timeBeginPeriod(1) at the start of the application sets the timer resolution to the lowest possible value (for this API) of 1 ms. After that I get minimum sleep times of roughly 1.8 ms.

I also translated the gist to Rust using the windows-rs crate and got even lower sleep times, but the results were quite unreliable. A sleep time of 1 ms sleeps between 0.8 ms (violates the rules of std::thread::sleep) and 1.8 ms. With this method the lowest sleep time is round about 0.8 ms. I had to use timeBeginPeriod as well, otherwise I still got a 15 ms resolution.

The first solution using timeBeginPeriod seems to be an easy way to get a better resolution. However, this is a system/process wide setting, depending on the version of Windows. I don't know if this has unintended consequences for other libraries/CPU usage and if we need to call timeEndPeriod at application shutdown or if Windows handles that automatically.

The second solution is much more complicated, because it does not guarantee a minimum sleep time. This means we would need additional code that checks for that.

Great resource for further reading: https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/

[joshtriplett]

cc @ChrisDenton for recommendations here.

[ChrisDenton]

I'm not entirely convinced we should be setting timeBeginPeriod for the application. Or even if we can do so cleanly in libraries. We do have to play well with others. So this feels like something that should be opted in to, especially as it affects the system (to a greater or lesser degree depending on the Windows version). It's also unclear to me if the added complexity of waitable timers will be worth it once you adjust for early wakes, but maybe it is.

To be clear, I'm not totally against it in principle. I'm just uncertain if this is practical for the standard library.