Previously the code below would not be guaranteed to exit when the first
spawned thread took the `return, // already unparked` path because there
was no write to synchronize with a read in `park`.
```
use std::sync::atomic::{AtomicBool, Ordering};
use std:🧵:{current, spawn, park};
static FLAG: AtomicBool = AtomicBool::new(false);
fn main() {
let thread_0 = current();
spawn(move || {
FLAG.store(true, Ordering::Relaxed);
thread_0.unpark();
});
let thread_0 = current();
spawn(move || {
thread_0.unpark();
});
while !FLAG.load(Ordering::Relaxed) {
park();
}
}
```
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<T: Send> Send for JoinHandle<T> {}
impl<T: Sync> Sync for JoinHandle<T> {}
```
Bound `T: Send` doesn't make much sense because `JoinHandle<T>` can be created only when `T: Send`. Note that [`JoinHandle::<T>::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<T>` cannot even share `T` - it can only send it to the thread that calls `join`.
park/park_timeout: prohibit spurious wakeups in next park
<pre><code>
// The implementation currently uses the trivial strategy of a Mutex+Condvar
// with wakeup flag, which does not actually allow spurious wakeups.
</pre></code>
Because does not actually allow spurious wakeups.
so we have let thread.inner.cvar.wait(m) in the loop to prohibit spurious wakeups.
but if notified after we locked, this notification doesn't be consumed, it return, the next park will consume this notification...this is also 'spurious wakeup' case, 'one unpark() wakeups two park()'.
We should improve this situation：
`thread.inner.state.store(EMPTY, SeqCst);`
This commit applies a few code size optimizations for the wasm target to
the standard library, namely around panics. We notably know that in most
configurations it's impossible for us to print anything in
wasm32-unknown-unknown so we can skip larger portions of panicking that
are otherwise simply informative. This allows us to get quite a nice
size reduction.
Finally we can also tweak where the allocation happens for the
`Box<Any>` that we panic with. By only allocating once unwinding starts
we can reduce the size of a panicking wasm module from 44k to 350 bytes.
Bump to 1.23 and update bootstrap
This commit updates the bootstrap compiler, bumps the version to 1.23, updates
Cargo, updates books, and updates crates.io dependencies
This is an adaptation of alexcrichton/futures-rs#597 for the standard library.
The goal here is to avoid locking a mutex on the "fast path" for thread
park/unpark where you're waking up a thread that isn't sleeping or otherwise
trying to park a thread that's already been notified. Mutex performance varies
quite a bit across platforms so this should provide a nice consistent speed
boost for the fast path of these functions.
Document thread builder panics for nul bytes in thread names
This seems to have been undocumented. Mention this where the name is set
(Builder::name) and where the panic could happen (Builder::spawn).
Thread::new is private and I think the builder is the only user where
this matters. A short comment was added to "document" Thread::new too.
This seems to have been undocumented. Mention this where the name is set
(Builder::name) and where the panic could happen (Builder::spawn).
Thread::new is private and I think the builder is the only user where
this matters. A short comment was added to "document" Thread::new too.
Add the libstd-modifications needed for the L4Re target
This commit adds the needed modifications to compile the std crate for the L4 Runtime environment (L4Re).
A target for the L4Re was introduced in commit: c151220a84
In many aspects implementations for linux also apply for the L4Re microkernel.
Some uncommon characteristics had to be resolved:
* L4Re has no network funktionality
* L4Re has a maximum stacksize of 1Mb for threads
* L4Re has no uid or gid
Co-authored-by: Sebastian Humenda <sebastian.humenda@tu-dresden.de>
