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 the parking_lot locking primitives #56410

Open
wants to merge 23 commits into
base: master
from

Conversation

Projects
None yet
9 participants
@faern
Contributor

faern commented Dec 1, 2018

This PR adds the parking_lot code to libstd and uses it for the sys_common::{mutex,rwlock,condvar,remutex} implementations.

This has been discussed in https://internals.rust-lang.org/t/standard-library-synchronization-primitives-and-undefined-behavior/8439/9

Thanks @Amanieu for mentoring when doing this, and basically all the code is his as well of course.

@rust-highfive

This comment was marked as outdated.

Collaborator

rust-highfive commented Dec 1, 2018

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

@Centril

This comment has been minimized.

Contributor

Centril commented Dec 1, 2018

@faern faern force-pushed the faern:add-parking-lot branch from 93093dc to 57526ff Dec 1, 2018

@Amanieu

This comment has been minimized.

Contributor

Amanieu commented Dec 1, 2018

Just to be clear, this PR only changes the "back-end" of the mutex implementation. There are no changes to the public Mutex API in libstd. API changes (such as const fn support) can be done in a later PR.

@nagisa

This comment has been minimized.

Contributor

nagisa commented Dec 1, 2018

There are no changes to the public Mutex API in libstd.

Isn’t there a difference between fairness of native Mutex and parking_lot’s Mutex?

EDIT: on some of the platforms, that is.

@Amanieu

This comment has been minimized.

Contributor

Amanieu commented Dec 1, 2018

Isn’t there a difference between fairness of native Mutex and parking_lot’s Mutex?

Any fairness was "implementation-defined" in the current implementation.

@Centril

Some observations; applies generally throughout the PR but I picked a few spots to illustrate. :)

pub struct UnparkHandle;
impl UnparkHandle {
// Wakes up the parked thread. This should be called after the queue lock is

This comment has been minimized.

@Centril

Centril Dec 1, 2018

Contributor

Documentation is a bit unclear re. when this is UB and not; do you mean "must" by "should"?
(Do a review of the PR in general to make the safety invariants clearer and more definitive... For example "Behavior is undefined if X")

This comment has been minimized.

@Amanieu

Amanieu Dec 1, 2018

Contributor

This is an internal API which is only used in the internals of parking_lot_core. Regarding your question: I used "should" here because you don't want to issue a system call while holding a lock, to keep lock durations short.

Show resolved Hide resolved src/libstd/sys_common/thread_parker.rs Outdated
Show resolved Hide resolved src/libstd/sys_common/thread_parker.rs
#[cold]
#[inline(never)]
unsafe fn unlock_slow(&self) {

This comment has been minimized.

@Centril

Centril Dec 1, 2018

Contributor

This is a lot of logic for an unsafe function and the invariants aren't stated;
It would be more readable to split it up into smaller chunks imo and also state the invariants required.
(Applies also to the function before this one).

This comment has been minimized.

@Amanieu

Amanieu Dec 1, 2018

Contributor

In this case the invariants are pretty simple: don't lock if the current thread already owns the lock and don't unlock if the current thread doesn't own the lock.

This comment has been minimized.

@Centril

Centril Dec 1, 2018

Contributor

@Amanieu Sure; but it should be stated in the code explicitly. :) and long unsafe fns are more risky imo; if you break it down a bit things can be reasoned about better.

This comment has been minimized.

@faern

faern Dec 4, 2018

Contributor

I have now managed to make three methods in this type not fully unsafe. And the only unsafe one left states why it is: unlock() must not be called on an already unlocked WordLock.

unreachable!();
} else {
enum Void {}
match *(1 as *const Void) {}

This comment has been minimized.

@Centril

Centril Dec 1, 2018

Contributor

Isn't there a cleaner way to do this? Dereferencing *const Void should be UB...?

This comment has been minimized.

@nagisa

nagisa Dec 1, 2018

Contributor

This is the stable pattern to get std::hint::unreachable_unchecked while unreachable was unstable. Should always use unreachable_unchecked now.

Show resolved Hide resolved src/libstd/sys_common/parking_lot_core/spinwait.rs Outdated
key: usize,
filter: &mut dyn FnMut(ParkToken) -> FilterOp,
callback: &mut dyn FnMut(UnparkResult) -> UnparkToken,
) -> UnparkResult {

This comment has been minimized.

@Centril

Centril Dec 1, 2018

Contributor

Also a very long unsafe function.

@faern faern referenced this pull request Dec 1, 2018

Merged

Backport libstd style #106

@faern faern force-pushed the faern:add-parking-lot branch from fb5360f to b4d3471 Dec 1, 2018

@rust-highfive

This comment was marked as outdated.

Collaborator

rust-highfive commented Dec 1, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:1c3ab440:start=1543686799054107223,finish=1543686801424514854,duration=2370407631
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:58:14] 
[00:58:14] running 119 tests
[00:58:17] i..ii...iii..iiii.....i...i.........i..iii.............i.....i.....ii...i..i.ii..............i...ii. 100/119
[00:58:18] .ii.i.....iiii.....
[00:58:18] 
[00:58:18]  finished in 3.641
[00:58:18] travis_fold:end:test_codegen

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:58:33] 
[00:58:33] running 118 tests
[00:58:58] .iiiii...i.....i..i...i..i.i..i.i..i.....i..i....i..........iiii.........i.i....i...i.......ii.i.i.i 100/118
[00:59:02] ......iii.i.....ii
[00:59:02] 
[00:59:02]  finished in 29.112
[00:59:02] travis_fold:end:test_debuginfo

---
[01:15:16] travis_fold:start:test_stage1-std
travis_time:start:test_stage1-std
Testing std stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:15:16]    Compiling std v0.0.0 (/checkout/src/libstd)
[01:15:19] error[E0432]: unresolved import `super::ReentrantMutex`
[01:15:19]   --> src/libstd/sys_common/parking_lot/remutex.rs:93:9
[01:15:19]    |
[01:15:19] 93 |     use super::ReentrantMutex;
[01:15:19]    |         ^^^^^^^^^^^^^^^^^^^^^ no `ReentrantMutex` in `sys_common::parking_lot::remutex`. Did you mean to use `RawReentrantMutex`?
[01:15:19] 
[01:15:19] error[E0432]: unresolved imports `Condvar`, `Mutex`
[01:15:19]    --> src/libstd/sys_common/parking_lot/condvar.rs:402:10
[01:15:19]     |
[01:15:19] 402 |     use {Condvar, Mutex};
[01:15:19]     |          ^^^^^^^  ^^^^^ no `Mutex` in the root
[01:15:19]     |          no `Condvar` in the root
[01:15:19] 
[01:15:19] 
j/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@faern faern force-pushed the faern:add-parking-lot branch from b4d3471 to e230096 Dec 1, 2018

@rust-highfive

This comment was marked as outdated.

Collaborator

rust-highfive commented Dec 1, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:1f2f2f49:start=1543692321136569642,finish=1543692323399010557,duration=2262440915
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:56:54] 
[00:56:54] running 119 tests
[00:56:57] i..ii...iii..iiii.....i...i.........i..iii.............i.....i.....ii...i..i.ii..............i...ii. 100/119
[00:56:57] .ii.i.....iiii.....
[00:56:57] 
[00:56:57]  finished in 3.461
[00:56:57] travis_fold:end:test_codegen

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:57:12] 
[00:57:12] running 118 tests
[00:57:36] .iiiii...i.....i..i...i..i.i..i.i..i.....i..i....i..........iiii.........i.i....i...i.......ii.i.i.i 100/118
[00:57:40] ......iii.i.....ii
[00:57:40] 
[00:57:40]  finished in 28.444
[00:57:40] travis_fold:end:test_debuginfo

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Dec 2, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:13ee08a4:start=1543709531669510421,finish=1543709533977542973,duration=2308032552
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:59:22] 
[00:59:22] running 119 tests
[00:59:25] i..ii...iii..iiii.....i...i.........i..iii.............i.....i.....ii...i..i.ii..............i...ii. 100/119
[00:59:25] .ii.i.....iiii.....
[00:59:25] 
[00:59:25]  finished in 3.668
[00:59:25] travis_fold:end:test_codegen

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:59:41] 
[00:59:41] running 118 tests
[01:00:07] .iiiii...i.....i..i...i..i.i..i.i..i.....i..i....i..........iiii.........i.i....i...i.......ii.i.i.i 100/118
[01:00:11] ......iii.i.....ii
[01:00:11] 
[01:00:11]  finished in 30.123
[01:00:11] travis_fold:end:test_debuginfo

---
[01:17:03] travis_fold:start:test_stage1-std
travis_time:start:test_stage1-std
Testing std stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:17:03]    Compiling std v0.0.0 (/checkout/src/libstd)
[01:17:06] error[E0432]: unresolved imports `Condvar`, `Mutex`
[01:17:06]    --> src/libstd/sys_common/parking_lot/condvar.rs:399:10
[01:17:06]     |
[01:17:06] 399 |     use {Condvar, Mutex};
[01:17:06]     |          ^^^^^^^  ^^^^^ no `Mutex` in the root
[01:17:06]     |          no `Condvar` in the root
[01:17:06] 
[01:17:19] error: aborting due to previous error
[01:17:19] 
[01:17:19] 
[01:17:19] For more information about this error, try `rustc --explain E0432`.
[01:17:19] error: Could not compile `std`.
[01:17:19] 
[01:17:19] To learn more, run the command again with --verbose.
[01:17:19] 
[01:17:19] 
[01:17:19] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "test" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--locked" "--color" "always" "--features" "panic-unwind backtrace" "--manifest-path" "/checkout/src/libstd/Cargo.toml" "-p" "std" "--" "--quiet"
[01:17:19] 
[01:17:19] 
[01:17:19] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test
[01:17:19] Build completed unsuccessfully in 0:29:07
[01:17:19] Build completed unsuccessfully in 0:29:07
[01:17:19] make: *** [check] Error 1
[01:17:19] Makefile:58: recipe for target 'check' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:00ae4529
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Sun Dec  2 01:29:43 UTC 2018

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@bors

This comment has been minimized.

Contributor

bors commented Dec 2, 2018

☔️ The latest upstream changes (presumably #56275) made this pull request unmergeable. Please resolve the merge conflicts.

@RalfJung

This comment has been minimized.

Member

RalfJung commented Dec 4, 2018

r? @RalfJung

FYI, I will not have time to look at this "+4168 −2426" PR this week. I should be able to get to it next week though.

I also feel slightly overwhelmed by the importance of this and would appreciate a co-reviewer -- maybe someone who actually has reviewed libstd code before :D

@faern

This comment has been minimized.

Contributor

faern commented Dec 4, 2018

I should add that I'm currently working on improving this code. Will likely push changes in a day or two. I have already backported some of the feedback here directly to parking_lot and have managed to, at least slightly, reduce the amount of unsafe. As soon as I have reached some good state and my tests pass I will push things here.

@faern faern force-pushed the faern:add-parking-lot branch from c62d50d to 910670f Dec 4, 2018

@bors

This comment has been minimized.

Contributor

bors commented Dec 7, 2018

☔️ The latest upstream changes (presumably #56066) made this pull request unmergeable. Please resolve the merge conflicts.

@faern faern force-pushed the faern:add-parking-lot branch 2 times, most recently from 2f15904 to abc062b Dec 9, 2018

@faern faern force-pushed the faern:add-parking-lot branch from abc062b to 9718fba Dec 9, 2018

@faern

This comment has been minimized.

Contributor

faern commented Dec 9, 2018

I could post some kind of benchmarks. The parking_lot repo has a benchmark sub-crate in it that can perform some micro benchmarking of the Mutex and RwLock types. Please keep in mind these are micro benchmarks, and also that the numbers varies quite a lot between runs as well.

Mutex

Built using latest nightly rustc/libstd:

$ cargo +nightly run --release --bin mutex -- 2 1 0 1 2
- Running with 2 threads
- 1 iterations inside lock, 0 iterations outside lock
- 1 seconds per test
        name         |    average     |     median     |    std.dev.   
parking_lot::Mutex   |  27880.651 kHz |  27643.931 kHz |    784.495 kHz
std::sync::Mutex     |   5760.698 kHz |   5983.312 kHz |    244.146 kHz
pthread_mutex_t      |   7557.519 kHz |   7640.839 kHz |    258.375 kHz

Built using the code currently in this PR (stage1 compiler):

$ cargo +stage1 run --release --bin mutex -- 2 1 0 1 2
- Running with 2 threads
- 1 iterations inside lock, 0 iterations outside lock
- 1 seconds per test
        name         |    average     |     median     |    std.dev.   
parking_lot::Mutex   |  26761.369 kHz |  28265.800 kHz |   3176.551 kHz
std::sync::Mutex     |  21122.531 kHz |  20840.200 kHz |   1490.975 kHz
pthread_mutex_t      |   7654.629 kHz |   7509.882 kHz |    648.945 kHz

RwLock

Built using latest nightly rustc/libstd:

$ cargo +nightly run --release --bin rwlock -- 1 1 1 0 1 2
- Running with 1 writer threads and 1 reader threads
- 1 iterations inside lock, 0 iterations outside lock
- 1 seconds per test
parking_lot::RwLock  - [write]  44619.796 kHz [read]  11551.274 kHz
seqlock::SeqLock     - [write]  27633.108 kHz [read]  31532.853 kHz
std::sync::RwLock    - [write]   6450.503 kHz [read]   4018.782 kHz
pthread_rwlock_t     - [write]  11007.401 kHz [read]   8722.818 kHz

Built using the code currently in this PR (stage1 compiler):

$ cargo +stage1 run --release --bin rwlock -- 1 1 1 0 1 2
- Running with 1 writer threads and 1 reader threads
- 1 iterations inside lock, 0 iterations outside lock
- 1 seconds per test
parking_lot::RwLock  - [write]  38818.641 kHz [read]  15724.790 kHz
seqlock::SeqLock     - [write]  27193.925 kHz [read]  38514.387 kHz
std::sync::RwLock    - [write]  34072.830 kHz [read]   2120.811 kHz
pthread_rwlock_t     - [write]   9255.783 kHz [read]   8181.922 kHz

All of the above was on Linux.

@faern faern force-pushed the faern:add-parking-lot branch from 9718fba to 1407c89 Dec 9, 2018

@rust-highfive

This comment has been minimized.

Collaborator

rust-highfive commented Dec 9, 2018

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
travis_time:end:10272717:start=1544322055945677727,finish=1544322057030175499,duration=1084497772
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout

Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#Pull-Requests-and-Security-Restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
Setting environment variables from .travis.yml
$ export IMAGE=x86_64-gnu-llvm-5.0
---
travis_time:start:test_codegen
Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:57:15] 
[00:57:15] running 120 tests
[00:57:18] i..ii...iii..iiii.....i...i..........i..iii.............i.....i.....ii...i..i.ii..............i...ii 100/120
[00:57:19] ..ii.i.....iiii.....
[00:57:19] 
[00:57:19]  finished in 3.598
[00:57:19] travis_fold:end:test_codegen

---
travis_time:start:test_debuginfo
Check compiletest suite=debuginfo mode=debuginfo-both (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[00:57:34] 
[00:57:34] running 118 tests
[00:57:58] .iiiii...i.....i..i...i..i.i..i.i..i.....i..i....i..........iiii.........i.i....i...i.......ii.i.i.i 100/118
[00:58:02] ......iii.i.....ii
[00:58:02] 
[00:58:02]  finished in 28.802
[00:58:02] travis_fold:end:test_debuginfo

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@faern

This comment has been minimized.

Contributor

faern commented Dec 9, 2018

I was able to remove the boxing of the inner locking type in the std::sync locking types. Since it's no longer important to keep the locks fixed at one memory address we don't need the box. For std::sync::Mutex this reduced indirection resulted in approximately 5% speedup in micro benchmarks on Linux, when there is contention. Compared to the performance std::sync::Mutex had with the code in this PR just before removing the boxing (the benchmarks posted above).

EDIT: Worth noting that this also affects the size of the synchronization structs. Mutex<()> went from 16 to 2 bytes.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Dec 11, 2018

I haven't had a ton of time to dig into this yet, but I'd ideally prefer that I get a chance to review/approve this before it lands as well. At a high-level I would ideally prefer that this uses parking_lot directly from crates.io rather than being bundled into std. That would make it far easier I think to run more comprehensive CI tests, make it easier to maintain/contribute to, and also share the core implementation with the external parking_lot crate as well. Depending on external crates.io crates isn't easy, but is being pioneered in another PR. Additionally this won't be as trivial a task as pulling in anything from crates.io, but we can work through the details.

Otherwise taking a strategy here of maintaining API parity and getting everything landed in an initial pass I think is a great way to start!

@faern

This comment has been minimized.

Contributor

faern commented Dec 11, 2018

Depending on the real parking_lot crate would of course be awesome for maintainability. I have been following the other PR you link to see the progress of that. So far most work I have put into this has been backported into parking_lot itself, so that does not set anything back.

The biggest problem is probably that parking_lot depend on a lot of libstd types. it uses Instant, Duration, thread::yield_now and maybe a few more things.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Dec 11, 2018

Oh dear, that could indeed be a problem! I think wrappers like thread::yield_now are probably thin enough (and libstd could call into parking_lot though? While Instant wouldn't be easily usable I think Duration is in core nowadays as well. Perhaps that would be enough to build a bare-bones API?

@Centril Centril requested a review from alexcrichton Dec 11, 2018

@Centril

This comment has been minimized.

Contributor

Centril commented Dec 11, 2018

@alexcrichton

I haven't had a ton of time to dig into this yet, but I'd ideally prefer that I get a chance to review/approve this before it lands as well.

I think that's a good idea; in fact, given the importance of this API it would be good for 2 more people to review this besides yourself and @RalfJung. Maybe someone from lang could review it? perhaps @aturon (tho they are on PTO...) or @eddyb ?

At a high-level I would ideally prefer that this uses parking_lot directly from crates.io rather than being bundled into std.

Hmm... one drawback with this is that it becomes difficult to use new unstable language features for asorted benefits... and is there some use for specialization that could be beneficial for perf that isn't exposed to users?

@faern

This comment has been minimized.

Contributor

faern commented Dec 11, 2018

While Instant wouldn't be easily usable I think Duration is in core nowadays as well. Perhaps that would be enough to build a bare-bones API?

Ah, I missed that we had Duration in core. That's something. A problem I see is that the underlying ThreadParker implementations need a way to measure elapsed time. The function signature that uses Instant looks like: park_until(&self, timeout: Instant). While I think it would be possible to make the user specify the timeout as a Duration, the algorithms still needs a way to measure elapsed time internally.

@Amanieu

This comment has been minimized.

Contributor

Amanieu commented Dec 11, 2018

The problem with specifying timeouts as a Duration is that it is subject to drift if there are spurious wakeups (the thread is woken up but somebody else has already grabbed the lock in the meantime). This is why I chose to convert all timeouts to Instant as soon as possible.

@alexcrichton

This comment has been minimized.

Member

alexcrichton commented Dec 12, 2018

Oh sorry for replacing Instant I meant moreso a possibility of considering all Duration instances as a "duration from a fixed point in time" rather than a relative "so many seconds from now". That may be difficult to work internally though?

Another option to use an external source of truth is to take a stdsimd-like approach where it's a submodule and not depended on via crates.io, just included directly into the crate via #[path]. One downside of that though is that it makes the crate itself a bit more difficult to develop

@bors

This comment has been minimized.

Contributor

bors commented Dec 14, 2018

☔️ The latest upstream changes (presumably #56490) made this pull request unmergeable. Please resolve the merge conflicts.

@faern

This comment has been minimized.

Contributor

faern commented Dec 14, 2018

It feels like it would be hard to avoid Instant? Not that I have really tried, but no one seems to have a good suggestion on how to do it. Even if we were to see Duration as a fixed point in time instead of a duration, we need a way to know the current point in time in many places, in order to know if our given deadline has passed or not.

I will experiment with adding it as a git submodule and see how that goes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment