rust/src/libstd/sync, branch perf-tmp

mv std libs to library/

2020-07-28T00:51:13+00:00

Rollup merge of #72414 - KodrAus:feat/stdlazy, r=Mark-Simulacrum

2020-07-18T01:13:39+00:00

Add lazy initialization primitives to std Follow-up to #68198 Current RFC: https://github.com/rust-lang/rfcs/pull/2788 Rebased and fixed up a few of the dangling comments. Some notes carried over from the previous PR: - [ ] Naming. I'm ok to just roll with the `Sync` prefix like `SyncLazy` for now, but [have a personal preference for `Atomic`](https://github.com/rust-lang/rfcs/pull/2788#issuecomment-574466983) like `AtomicLazy`. - [x] [Poisoning](https://github.com/rust-lang/rfcs/pull/2788#discussion_r366725768). It seems like there's [some regret around poisoning in other `std::sync` types that we might want to just avoid upfront for `std::lazy`, especially if that would align with a future `std::mutex` that doesn't poison](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/parking_lot.3A.3AMutex.20in.20std/near/190331199). Personally, if we're adding these types to `std::lazy` instead of `std::sync`, I'd be on-board with not worrying about poisoning in `std::lazy`, and potentially deprecating `std::sync::Once` and `lazy_static` in favour of `std::lazy` down the track if it's possible, rather than attempting to replicate their behavior. cc @Amanieu @sfackler. - [ ] [Consider making`SyncOnceCell::get` blocking](https://github.com/matklad/once_cell/pull/92). There doesn't seem to be consensus in the linked PR on whether or not that's strictly better than the non-blocking variant. In general, none of these seem to be really blocking an initial unstable merge, so we could possibly kick off a FCP if y'all are happy? cc @matklad @pitdicker have I missed anything, or were there any other considerations that have come up since we last looked at this?

Rollup merge of #73269 - mzohreva:mz/sgx-wait-timeout, r=jethrogb

2020-07-17T00:08:56+00:00

Enable some timeouts in SGX platform This would partially resolve https://github.com/fortanix/rust-sgx/issues/31 cc @jethrogb and @Goirad

appease tidy

2020-07-16T21:25:32+00:00

remove inlined lazy::Waiter in favor of sync::Once

2020-07-16T21:25:32+00:00

Rollup merge of #73104 - poliorcetics:explicit-mutex-drop-example, r=dtolnay

2020-06-15T10:01:07+00:00

Example about explicit mutex dropping Fixes #67457. Following the remarks made in #73074, I added an example on the main `Mutex` type, with a situation where there is mutable data and a computation result. In my testing it is effectively needed to explicitly drop the lock, else it deadlocks. r? @dtolnay because you were the one to review the previous PR.

Rewrap comments in Mutex example

2020-06-13T17:11:02+00:00

Clarify the scope-related explanation

2020-06-13T16:43:37+00:00

Based on the review made by dtolnay.

Apply suggestions from code review

2020-06-13T16:41:01+00:00

Co-authored-by: David Tolnay

Enable some timeouts in SGX platform

2020-06-12T18:26:19+00:00

This would partially resolve https://github.com/fortanix/rust-sgx/issues/31