-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
std: Redesign Duration, implementing RFC 1040 #24920
Conversation
r? @pcwalton (rust_highfive has picked a reviewer for you, use r? to override) |
r? @aturon cc @wycats The only "surprise" I had during the implementation was the naming of the methods here and there. Abbreviating "seconds" as "secs" didn't feel super rustic to me, but typing millis/nanos felt much better than milliseconds/nanoseconds. Overall I didn't feel too strongly either way! |
c0d3aa8
to
260ce79
Compare
let seconds = self.secs; | ||
let millis = self.nanos / NANOS_PER_MILLI; | ||
let nanos = self.nanos % NANOS_PER_MILLI; | ||
match (seconds, millis, nanos) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the motivation for this sort of 'complicated' formatting rather than something like, say, 1234.00000567s
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not particularly wed to this format, but it's what was specified in the RFC (as a starting point). I also had some reservations and wouldn't mind changing it to be only numeric as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I also have mixed feelings about this actually looking at this code (I should have raised this with the RFC). I think that automatically figuring out whether to use seconds, millis, or nanos is a good idea, but I don't understand the motivation for XX seconds and XX nanoseconds
.
☔ The latest upstream changes (presumably #24888) made this pull request unmergeable. Please resolve the merge conflicts. |
☔ The latest upstream changes (presumably #24967) made this pull request unmergeable. Please resolve the merge conflicts. |
@@ -57,25 +57,20 @@ impl Condvar { | |||
// https://github.com/llvm-mirror/libcxx/blob/release_35/src/condition_variable.cpp#L46 | |||
// https://github.com/llvm-mirror/libcxx/blob/release_35/include/__mutex_base#L367 | |||
pub unsafe fn wait_timeout(&self, mutex: &Mutex, dur: Duration) -> bool { | |||
if dur <= Duration::zero() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes the behavior for a zero duration; intended?
@alexcrichton Ok, I've done a preliminary pass. Looks nice a simple. I raised a few concerns (most of which, to be honest, I should have raised on the RFC). |
Ok I have updated some feedback and discussion with @aturon:
re-r? @aturon |
2fe4199
to
f143b01
Compare
return Thread::yield_now() | ||
} | ||
let seconds = dur.num_seconds(); | ||
let ns = dur - Duration::seconds(seconds); | ||
let mut ts = libc::timespec { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should exist From<Duration> for libc::timespec
in liblibc instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately this can't be provided in liblibc because Duration
doesn't exist by that point and due to the in-tree liblibc
being different from the out-of-tree liblibc
it unfortunately also wouldn't work to provide this in the standard library as well.
Thanks for taking a look @nagisa! |
@bors: r+ |
📌 Commit 086fddc has been approved by |
Thanks @alexcrichton! |
⌛ Testing commit 086fddc with merge 9eb94a8... |
💔 Test failed - auto-mac-64-nopt-t |
|
cd06e02
to
38cfc7a
Compare
⌛ Testing commit 38cfc7a with merge 9b165c0... |
💔 Test failed - auto-win-64-opt |
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the currently-unstable `Duration` type. The API of the type has been scaled back to be more conservative and it also no longer supports negative durations. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md The inner `duration` module of the `time` module has now been hidden (as `Duration` is reexported) and the feature name for this type has changed from `std_misc` to `duration`. All APIs accepting durations have also been audited to take a more flavorful feature name instead of `std_misc`. Closes rust-lang#24874
⌛ Testing commit 556e76b with merge 0755c09... |
💔 Test failed - auto-linux-32-nopt-t |
@bors: retry On Wed, May 13, 2015 at 8:36 PM, bors notifications@github.com wrote:
|
This commit is an implementation of [RFC 1040][rfc] which is a redesign of the currently-unstable `Duration` type. The API of the type has been scaled back to be more conservative and it also no longer supports negative durations. [rfc]: https://github.com/rust-lang/rfcs/blob/master/text/1040-duration-reform.md The inner `duration` module of the `time` module has now been hidden (as `Duration` is reexported) and the feature name for this type has changed from `std_misc` to `duration`. All APIs accepting durations have also been audited to take a more flavorful feature name instead of `std_misc`. Closes #24874
This commit is an implementation of RFC 1040 which is a redesign of the
currently-unstable
Duration
type. The API of the type has been scaled back tobe more conservative and it also no longer supports negative durations.
The inner
duration
module of thetime
module has now been hidden (asDuration
is reexported) and the feature name for this type has changed fromstd_misc
toduration
. All APIs accepting durations have also been audited totake a more flavorful feature name instead of
std_misc
.Closes #24874