You can't rely on something like thread::sleep_ms for that kind of accuracy. You need to look at the current time, compute when you want to "wake up", do your work, check the time again, ask the OS to sleep for an appropriate amount of time... and when you're woken up, work out the error between when you wanted to wake up and when you actually woke up, and adjust the next wake up time accordingly.
Also, the code you actually execute does add to the time needed for execution.
Probably it is the println!() here.
Edit: if you use thread::sleep_ms() your application stops executing and insdead gives control to the OS (which is scheduling all of your processes). If the OS thinks any other task is mor important than your program it could be that it accidentially waits more than a minute.
Also, if you need to use thread::sleep_ms() anywhere in your code, you have a problem with your applications design anyway, except in some very, very few cases.
If you need really high precision it would be better to use a Real Time Operating System, not Windows.
I am afraid I cannot help you any further as I don't know if there is a crate out there which let's you register a callback function which is then periodically called, what might be the best solution.
That is worded too strongly, IMO. There are quite a few situations where a thread can sit in the background, waking up periodically and doing some work, maybe checking files for updates, or doing some kind of "garbage collection" (not in the memory management sense).
I know. I just try to teach people to not use it if there is anything else they can do, without sacrificing performance of course.
I always try to utilize I/O so I can wait for something in the file to actually be written.
Also one can use channels if working with threads, or simply try to not leave any garbage in the first-place.
One use I could understand was sending _ping_s on some socket to keep the connection up/notify that you are still there, but out of that? Not really much.
Also it is okay to use in a W.I.P. but IMO there should be no, or at least only few well documented sleep()s in finished applications.