Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: use CLOCK_BOOTTIME for nanotime() #25248

Closed
zx2c4 opened this issue May 4, 2018 · 1 comment
Closed

runtime: use CLOCK_BOOTTIME for nanotime() #25248

zx2c4 opened this issue May 4, 2018 · 1 comment

Comments

@zx2c4
Copy link
Contributor

zx2c4 commented May 4, 2018

Go's timers appear to use nanotime(). nanotime() at the moment uses CLOCK_MONOTONIC. This is all good and well, until you're trying to do networking on a mobile device. Imagine a protocol that is supposed to do something upon the expiration of a timer with a certain bit of wiggle room. If it doesn't after the wiggle room, availability is affected. If a smartphone goes to sleep, when it wakes back up, if it leaves off counting where it left off, the timer's expiration will happen way too late. Instead, when it wakes back up, if the timer has already expired, it should be immediately expired.

Fortunately, Linux offers CLOCK_BOOTTIME, which according to the man page is identical to CLOCK_MONOTONIC, except it takes into account suspend. (It isn't susceptible to the administrator fiddling the clock like CLOCK_REALTIME is, which obviously would not be what we want.) Check out the clock_gettime man page for descriptions.

The patch for this is straightforward, but I figure I should post about it here first to see if you've already thought about this.

@cespare
Copy link
Contributor

cespare commented May 4, 2018

Yep, we've been discussing this recently. Duplicate of #24595.

@cespare cespare closed this as completed May 4, 2018
@golang golang locked and limited conversation to collaborators May 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants