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`.
Improve cleaning of the bottom of the backtrace
Following https://github.com/rust-lang/rust/pull/40264. It only cleans the bottom of the trace (after the main). It handles correctly the normal main, tests, benchmarks and threads.
I kept `skipped_before` since it will be used later for the cleaning of the top.
When `RUST_BACKTRACE=1`, remove all frames after
`__rust_maybe_catch_panic`. Tested on `main`, threads, tests and
benches. Cleaning of the top of the stacktrace is let to a future PR.
Fixes#40201
See #41815
[Doc] improve `thread::Thread` and `thread::Builder` documentations
Part of #29378
- Adds information about the stack_size when using `Builder`. This might be considered too low level, but I assume that if someone wants to create their own builder instead of using `thread::spawn` they may be interested in that info.
- Updates the `thread::Thread` structure doc, mostly by explaining how to get one, the previous example was removed because it was not related to `thread::Thread`, but rather to `thread::Builder::name`.
Not much is present there, mostly because this API is not often used (the only method that seems useful is `unpark`, which is documented in #41809).
Add an example to std:🧵:Result type
This PR is a part of https://github.com/rust-lang/rust/issues/29378. I submit this PR with the help (mentoring) of @steveklabnik. I'm still not sure my request is good enough but I don't want to spoil the issue with too much questions so I continue here. r? @steveklabnik
Windows historically has problems with threads panicking and the main thread
exiting at the same time, typically causing deadlocks. In the past (#25824)
we've joined on threads but this just prevents running the test for now to avoid
tampering with the example.
