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.
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.
* Moves docs about stack size and thread naming from `Builder` to the
`std::thread` module
* Adds more links to the new module-level documentation
* Mentions the 2 MiB stack size default, but indicate it's subject to
change
Fixes https://github.com/rust-lang/rust/issues/43805.
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
[Doc] Expands `detach` documentation in `thread::JoinHande`.
Part of #29378 .
- Adds an example of a thread detaching.
- Expands what `detaching` means.
r? @steveklabnik
[Doc] Add `'static` and `Send` constraints explanations to `thread::spawn`
Part of #29378.
Explains why the constraints on the closure and its return value are `'static` and `Send`.
Allows to tick of `thread::spawn` from the list of things to document in the `thread` module.
r? @steveklabnik
[Doc] Implrove `thread::Builder`'s doc.
Part of #29378 .
- Explains *why* we would use the builder instead ofthe free function.
- Changes the parent-child explanation for a spawned-caller in `thread::Builder::spawn`
- Adds a link to `io::Result` in `thread::Builder`
- Corrects the return type doc in `thread::Builder::spawn`
r? @rust-lang/docs
Part of #29378 .
- In particular explains *why* we would use the builder instead of
the free function.
- Changes the parent-child explanation for a spawned-caller.
- Add link to `io::Result` in `thread::Builder`
- Corrects the `thread::Builder::spawn` documentation.
[Doc] Improve `thread::spawn` documentation
Part of #29378
- Add two examples to `thread::spawn` doumentation that show common uses of threads.
- Add a link to `thread::Builder` in the `thread::spawn` documentation for configuring threads.
- Add a link to `thread::spawn` in `thread::Builder` in order to avoid documentation duplication.
r? @steveklabnik
[DOC] Improve the thread::park and thread::unpark documentation
Part of #29378 .
Takes care of the documentation for `park`, `park_duration` and also improves the `unpark` example.
- `park should` have its module documentation inlined here, and cleaned up.
- `park_timeout` could use links to `park`.
