`Timer` is paused on Android in "doze" state

[link2xt]

Because std::time::Instant is implemented using libc::clock_gettime(CLOCK_MONOTONIC) and this time does not advance on Android while the app is in "doze" state, the timer may be effectively paused on Android: https://users.rust-lang.org/t/std-now-with-android/41774

One way to fix this is to use SystemTime instead and handle time occasionally going backwards properly. Another is to lift this issue to the standard library so it uses Android-specific ioctl on /dev/alarm as described here: https://users.rust-lang.org/t/std-now-with-android/41774/2

[taiki-e]

Another is to lift this issue to the standard library so it uses Android-specific ioctl on /dev/alarm as described here:

See rust-lang/rust#71860

[nullchinchilla]

Commenting to note that this behavior is actually desirable in my use case, as it prevents massive thundering-herds of timers suddenly expiring when Doze ends, something I've seen in Go.

My use case does involve massive amounts of small, fine-grained timers (essentially a userspace TCP implementation), so it's somewhat of a worst-case for this though.

[notgull]

With Rust 1.64 coming out in a month or so, this issue should be fixed on libstd relatively soon. I'd rather wait for it to be fixed on that end than implement a patch in here that will soon become unnecessary.

[notgull]

As of Rust 1.64, the Instant type now uses CLOCK_BOOTTIME, which should close this issue.

[notgull]

Actually, I just remembered that polling uses CLOCK_MONOTONIC, so I should reopen this issue until that is fixed.

[link2xt]

As of Rust 1.64, the Instant type now uses CLOCK_BOOTTIME, which should close this issue.

This URL points to line with CLOCK_MONOTONIC, and if I switch to master, it's still CLOCK_MONOTONIC. Where does the Instant implementation use CLOCK_BOOTTIME constant?

There is a PR proposing a switch to CLOCK_BOOTTIME, but it's not merged: rust-lang/rust#88714