Skip to content

Which order to run box annihilator and TLS dtor? #8302

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.

Sign up for GitHub

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

Jump to bottom
Closed
brson opened this issue Aug 5, 2013 · 7 comments
Closed

Which order to run box annihilator and TLS dtor? #8302

brson opened this issue Aug 5, 2013 · 7 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows

Comments

@brson
Copy link
Contributor

brson commented Aug 5, 2013

It looks like in the current codebase we need to run the annihilator before the TLS dtor because rustc has boxes in cycles that access TLS, but TLS dtors could also create cycles requiring GC. Not sure how to resolve this interdependency.
@brson
Copy link
Contributor Author

brson commented Aug 5, 2013

Actually, not sure what's going on here. It's late. Need sleep.

brson added a commit to brson/rust that referenced this issue Aug 5, 2013
@brson
std::rt: Use magic to make TLS work from annihilated boxes. rust-lang…
1c1add2 
…#8302
@brson
Copy link
Contributor Author

brson commented Aug 5, 2013

This is exposed in a few compile-fail tests including infinite-instantiation.

@bblum
Copy link
Contributor

bblum commented Aug 5, 2013

Is the LocalStorage version of TLS not used exclusively by the stdlib? If it is, we could just rtabort if a TLS destructor tries to use @-pointers.

Definitely related to #6996. There may be no way around it no matter which runtime is plugged in. It strikes me as "just as bad" as failing from a destructor while unwinding.

@brson
Copy link
Contributor Author

brson commented Aug 5, 2013

LocalStorage is just the type used to hold the opaque pointer used by the TLS implementation. It holds the map of all the task local values, including arbitrary destructors.

@alexcrichton alexcrichton mentioned this issue Oct 11, 2013
Closed
@alexcrichton
Copy link
Member

Note that this is likely also concerned modifying TLS when destroying TLS, or possibly creating @ when destroying @

@pnkfelix
Copy link
Member

cc me

@thestinger
Copy link
Contributor

Gc has been removed so this is no longer relevant.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jan 17, 2022
@bors
Auto merge of rust-lang#8302 - xFrednet:0000-move-return-self-not-mus…
72c59fd 
…t-use, r=flip1995

Move `return_self_not_must_use` to `pedantic`

r? `@flip1995`

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@alexcrichton @brson @pnkfelix @thestinger @bblum