-
Notifications
You must be signed in to change notification settings - Fork 14.1k
thread::scope: document how join interacts with TLS destructors #149482
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
base: main
Are you sure you want to change the base?
Conversation
|
r? @ChrisDenton rustbot has assigned @ChrisDenton. Use |
d30b158 to
1deb487
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, this truly matches current behaviour. I really like that this is phrased in a way that still leaves the possibility of fixing this in the future.
|
This looks correct to me based on the current implementation and previous discussion. But it does probably warrant a libs-api sign-off so I'll nominate it. It is not great that implicit joins can't currently offer the same guarantees as explicit ones so we do want to keep the door open to future improvements. On the flip side, this does close off the possibility of providing weaker guarantees for explicit joins in the future but I'd consider that a very good thing. I'd always want some way to wait until a thread is fully finished running. |
|
@rfcbot merge libs-api |
|
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
|
Just to be clear the libs-api FCP is specifically for guaranteeing that an explicit |
Fixes #116237 by documenting the current behavior regarding thread-local destructors as intended. (I'm not stoked about this, but documenting it is better than leaving it unclear.)
This also adds documentation for explicit
joincalls (both for scoped and regular threads), saying that those will wait for TLS destructors. That reflects my understanding of the current implementation, which callsjoinon the native thread handle. Are we okay with guaranteeing that? I think we should, so people have at least some chance of implementing "wait for all destructors" manually. This fixes #127571.Cc @rust-lang/libs-api