rust/src/libstd/thread, branch 1.30.0

split paragraph

2018-08-28T08:49:45+00:00

document effect of join on memory ordering

2018-08-15T13:22:54+00:00

avoid using the word 'initialized' to talk about that non-reentrant-capable state of the mutex

2018-08-08T16:12:33+00:00

actually, reentrant uninitialized mutex acquisition is outright UB

2018-08-06T12:39:55+00:00

clarify partially initialized Mutex issues

2018-08-06T10:54:44+00:00

Rollup merge of #52771 - matklad:patch-1, r=kennytm

2018-08-01T08:12:38+00:00

Clarify thread::park semantics It took me quite some time to realize that the example is not actually racy, so let's clarify it? :-)

Rollup merge of #52759 - stjepang:impl-send-sync-for-joinhandle, r=TimNN

2018-07-28T08:24:59+00:00

Impl Send & Sync for JoinHandle This is just a cosmetic change - it slightly relaxes and clarifies the public API without effectively promising any new guarantees. Currently we have [these auto trait implementations](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#synthetic-implementations): ```rust impl Send for JoinHandle {} impl Sync for JoinHandle {} ``` Bound `T: Send` doesn't make much sense because `JoinHandle` can be created only when `T: Send`. Note that [`JoinHandle::::join`](https://doc.rust-lang.org/nightly/std/thread/struct.JoinHandle.html#method.join) doesn't require `T: Send` so why should the `Send` impl? And the `Sync` impl doesn't need `T: Sync` because `JoinHandle` cannot even share `T` - it can only send it to the thread that calls `join`.

Fix ws

2018-07-27T11:44:20+00:00

Clarify thread::park semantics

2018-07-27T11:01:42+00:00

Add stability attributes

2018-07-27T08:08:02+00:00