And here we come upon a sad state of affairs. The whole point of Instant is that it’s monotonically increasing. We’ve found in the wild, however, that it’s not actually monotonically increasing for one reason or another. These appear to be OS and hardware level bugs, and there’s not really a whole lot we can do about them. Here’s a taste of what we’ve found:
It simply seems that this it just happens so that a lot in the wild we’re seeing panics across various platforms where consecutive calls to Instant::now, such as via the elapsed function, are panicking as they’re going backwards. Placed here is a last-ditch effort to try to fix things up. We keep a global “latest now” instance which is returned instead of what the OS says if the OS goes backwards.
To hopefully mitigate the impact of this though a few platforms are whitelisted as “these at least haven’t gone backwards yet”.
It appears they are running into problems due to using CLOCK_MONOTONIC, which is affected by stuff like NTP and adjtime instead of something like CLOCK_MONOTONIC_RAW (exposed through clock_gettime). I don’t understand why they couldn’t switch to that on linux. Presumably bsd has something similar.
I shall quote the long block comment in full:
I would very much like to know more about the circumstances in which the monotonic clock goes backwards on OpenBSD.
Jiří Navrátil reported so here. I don’t see much relevant details, but maybe it’s different for you?
Yeah, unfortunately that tells me nothing. :(
It appears they are running into problems due to using CLOCK_MONOTONIC, which is affected by stuff like NTP and adjtime instead of something like CLOCK_MONOTONIC_RAW (exposed through
clock_gettime). I don’t understand why they couldn’t switch to that on linux. Presumably bsd has something similar.I recommend reading adjtime man page. adjtime do not cause monotonicity violation.