-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
removed references to parent/child from std::thread documentation #87848
removed references to parent/child from std::thread documentation #87848
Conversation
- also clarifies how thread.join and detaching of threads works - the previous prose implied that there is a relationship between a spawning thread and the thread being spawned, and that "child" threads couldn't outlive their parents unless detached, which is incorrect.
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors r+ rollup |
📌 Commit 2a56a4f has been approved by |
…ation-fix, r=joshtriplett removed references to parent/child from std::thread documentation - also clarifies how thread.join and detaching of threads works - the previous prose implied that there is a relationship between a spawning thread and the thread being spawned, and that "child" threads couldn't outlive their "parents" unless detached, which is incorrect.
…ation-fix, r=joshtriplett removed references to parent/child from std::thread documentation - also clarifies how thread.join and detaching of threads works - the previous prose implied that there is a relationship between a spawning thread and the thread being spawned, and that "child" threads couldn't outlive their "parents" unless detached, which is incorrect.
Rollup of 14 pull requests Successful merges: - rust-lang#86840 (Constify implementations of `(Try)From` for int types) - rust-lang#87582 (Implement `Printer` for `&mut SymbolPrinter`) - rust-lang#87636 (Added the `Option::unzip()` method) - rust-lang#87700 (Expand explanation of E0530) - rust-lang#87811 (Do not ICE on HIR based WF check when involving lifetimes) - rust-lang#87848 (removed references to parent/child from std::thread documentation) - rust-lang#87854 (correctly handle enum variants in `opt_const_param_of`) - rust-lang#87861 (Fix heading colours in Ayu theme) - rust-lang#87865 (Clarify terms in rustdoc book) - rust-lang#87876 (add `windows` count test) - rust-lang#87880 (Remove duplicate trait bounds in `rustc_data_structures::graph`) - rust-lang#87881 (Proper table row formatting in platform support) - rust-lang#87889 (Use smaller spans when suggesting method call disambiguation) - rust-lang#87895 (typeck: don't suggest inaccessible fields in struct literals and suggest ignoring inaccessible fields in struct patterns) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
I wonder, does this mean that the answer at https://stackoverflow.com/a/55228719/563359 is incorrect? Are there any guarantees to what happens to a detached thread when |
I don't have the time to review answers on Internet Q&A sites, but the Rust documentation with my fixes is correct. When main() returns, exit() will be called, which terminates the entire process including all threads running in it. It's this way in C, C++, and Rust also. Rust threads aren't special - they have the same semantics as that which is specified by POSIX, the standard on top of which they are implemented in Linux at least. There is no parent-child relationship between threads, either. Any thread can join any joinable thread. Detached threads cannot be joined. Reading this information misrepresented in the 2018 version of the documentation prompted this PR. |
spawning thread and the thread being spawned, and that "child" threads
couldn't outlive their "parents" unless detached, which is incorrect.