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

Use saturating_duration_since in elapsed instead of panicking #84344

Closed
wants to merge 1 commit into from

Conversation

isg
Copy link

@isg isg commented Apr 19, 2021

This seems like a strict improvement over panicking when the current clock is now behind.

Fixes #80674.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 19, 2021
@the8472
Copy link
Member

the8472 commented Apr 20, 2021

A guaranteed-monotonic clock going backwards either indicates a programming error (you swapped the start and end Instants) or a hardware bug. Silently papering over those is not a good idea.

Users can explicitly use the saturating or checked variants if they don't care about broken clocks or know that their instants aren't always properly ordered.

@isg
Copy link
Author

isg commented Apr 20, 2021

either indicates a programming error (you swapped the start and end Instants) or a hardware bug

My thinking was that in this case, it's an internal usage so programming error is ruled out. It's true that it could be papering over the clock issue, but perhaps if it's documented (as was the panic) that's acceptable? Here I'm biasing toward supporting long-running processes where folks may have worked hard to avoid panics (i.e. no unwraps, expects, etc).

Totally understand if we think a loud panic is better, it just seems unfortunate to have elapsed be unsafe to use.

@joshtriplett
Copy link
Member

joshtriplett commented Apr 20, 2021

There's an explicit mechanism to make sure that timestamps never go backwards, specifically to avoid this issue.

I can very easily imagine code having an issue if it gets back a zero duration, as well.

I think we should keep elapsed as it is.

EDIT: I no longer feel this way, and I think a zero is preferable to a panic.

@isg
Copy link
Author

isg commented Apr 20, 2021

Fair enough, thanks for the prompt review!

@isg isg closed this Apr 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

panic in elapsed()
4 participants