Description
Instant::now
currently uses CLOCK_MONOTONIC
, which stops ticking during suspend. This means that creating a Duration
via Instant::duration_since
will be notably shorter than expected if the system suspended between the &self
instance and the earlier
argument.
If CLOCK_BOOTTIME
is used instead, the clock is guaranteed to continue ticking during suspend. This closer matches the documentation and real world usage of Instant
. The documentation for Instant::duration_since
reads "Returns the amount of time elapsed from another instant to this one." - no mention of an exception for suspend or other low power states. tokio
uses Instant
to govern its sleep and timeout functionality. Given that tokio
is commonly used to implement network servers and clients, slicing out suspended time was likely not their intention.
Using CLOCK_BOOTTIME
should have minimal impact on existing usage. Performance-wise, CLOCK_BOOTTIME
is implemented in Linux by getting the CLOCK_MONOTONIC
time and adding an offset to it. That offset is updated as part of exiting suspend. As a result, the total cost should be an extra two loads , two adds, and maybe two stores with bad optimization, which are all negligible compared to the cost of servicing a system call. In terms of existing applications, the only ones which will see new behavior is ones which are measuring time across suspends. The only use case I can think of for wanting the old CLOCK_MONOTONIC
behavior is time-multiplexing system resources, but I am not aware of an actual user.
Other projects on the same issue
- Go decided against switching its runtime to use
CLOCK_BOOTTIME
due to - Linux converted
CLOCK_MONOTONIC
to act likeCLOCK_BOOTTIME
since it was almost always the desired behavior, and technically spec compatible, but reverted it shortly afterwards due to compatibility issues.