Tracking issue for `thread_local` stabilization

[aturon]

The #[thread_local] attribute is currently feature-gated. This issue tracks its stabilization.

Known problems:

• #[thread_local] translates directly to the thread_local attribute in LLVM. This isn't supported on all platforms, and it's not even supported on all distributions within the same platform (e.g. 10.6 doesn't support it but 10.7 does). I don't think this is necessarily a blocker, but I also don't think we have many attributes and such which are so platform specific like this.
• Statics that are thread local shouldn't require Sync - #18001
• Statics that are thread local should either not borrow for the 'static lifetime or should be unsafe to access - #17954
• Statics can currently reference other thread local statics, but this is a bug - #18712
• Unsound with generators #49682
• static mut can be given 'static lifetime with NLL (#54366)

[aturon]

@alexcrichton Can you elaborate on the blockers?

[alexcrichton]

Certainly! Known issues to me:

• #[thread_local] translates directly to the thread_local attribute in LLVM. This isn't supported on all platforms, and it's not even supported on all distributions within the same platform (e.g. 10.6 doesn't support it but 10.7 does). I don't think this is necessarily a blocker, but I also don't think we have many attributes and such which are so platform specific like this.
• Statics that are thread local shouldn't require Sync - #18001
• Statics that are thread local should either not borrow for the 'static lifetime or should be unsafe to access - #17954
• Statics can currently reference other thread local statics, but this is a bug - #18712

That's at least what I can think of at this time!

[alexcrichton]

A note, we've since implemented cfg(target_thread_local) which is in turn itself feature gated, but this may ease the "this isn't implemented on all platforms" worry.

[alexandermerritt]

Hi! Is there any update on the status? Nightly still requires statics to be Sync. I tried with:

rustc 1.13.0-nightly (acd3f796d 2016-08-28)
binary: rustc
commit-hash: acd3f796d26e9295db1eba1ef16e0d4cc3b96dd5
commit-date: 2016-08-28
host: x86_64-unknown-linux-gnu
release: 1.13.0-nightly

[mneumann]

@alexcrichton Any news on #[thread_local] becoming stabilized? AFAIK, at the moment it is impossible on DragonFly to access errno variable from stable code, other than directly from libstd. This blocks crates like nix on DragonFly, which want to access errno as well, but libstd is not exposing it, and stable code is not allowed to use feature(thread_local).

[alexcrichton]

@mneumann no, no progress. I'd recommend a C shim for now.

[mneumann]

@alexcrichton thanks. I am doing a shim now https://github.com/mneumann/errno-dragonfly-rs.

[Boiethios]

The optimizations are too aggressive ;)

See this code:

#![feature(thread_local)]

#[thread_local]
pub static FOO: [&str; 1] = [ "Hello" ];

fn change_foo(s: &'static str) {
    FOO[0] = s;
}

fn main() {
    println!("{}", FOO[0]);
    change_foo("Test");
    println!("{}", FOO[0]);
}

The compiler does not detect the side effect in change_foo and removes the call in release. The output is:

Hello
Hello

[alexcrichton]

cc @eddyb, @Boiethios your example shouldn't actually compile because it should require static mut, not just static

[Boiethios]

It compiles with the last nightly rustc.

[eddyb]

Oh, drat, this is from my shortening of the lifetime, i.e

rust/src/librustc/middle/mem_categorization.rs

Lines 657 to 662 in dead08c

	// `#[thread_local]` statics may not outlive the current function.
	for attr in &self.tcx.get_attrs(def_id)[..] {
	if attr.check_name("thread_local") {
	return Ok(self.cat_rvalue_node(id, span, expr_ty));
	}
	}

@nikomatsakis what should we do here? I want a static lvalue, with a non-'static lifetime.

[cramertj]

#18001, #17954 and #18712 were fixed by #43746.

@alexcrichton @eddyb Do you know any other blockers, or is this ready for stabilization?

[eddyb]

There's some emulation clang does IIRC, that we might want to do ourselves, to support #[thread_local] everywhere.

And there's #47053 which results from my initial attempt to limit references to thread-local statics to the function they were created in.

[alexcrichton]

@cramertj I've personally been under the impression that we're holding out on stabilizing this for as long as possible. We've stabilized very few (AFAIK) platform-specific attributes like this and I at least personally haven't ever looked to hard into stabilizing this.

One blocker (in my mind at least) is what @eddyb mentioned where this is a "portable" attribute yet LLVM has a bunch of emulation on targets that don't actually support it (I think MinGW is an example). I don't believe we should allow the attribute on such targets, but we'd have to do a lot of investigation to figure out those targets.

Is there motivation for stabilizing this though? That'd certainly provide some good motivation for digging out any remaining issues and looking at it very closely. I'd just personally been under the impression that there's little motivation to stabilize this other than it'd be a "nice to have" in situations here and there.

[Amanieu]

I am using #[thread_local] in my code in a no_std context: I allocate space for the TLS segment and set up the architecture TLS register to point to it. Therefore I think that it is important to expose the #[thread_local] attribute so that it can at least be used by low-level code.

The only thing that I'm not too happy about is that Sync is no longer required for #[thread_local]: this makes it more difficult to write signal-safe code, since all communication between signal handlers and the main thread should be done through atomic types.

[eddyb]

@Amanieu Signal/interrupt-safe code has other requirements which are not satisfied by current Rust.

[Amanieu]

@eddyb Not really, all you need to do is treat the signal handler as a separate thread of execution. The only requirement you need to enforce safety is that objects which are accessed by both the main thread and the signal handler must be Sync.

Of course you can still cause deadlocks if the main thread and signal handler both try to grab the same lock, but that's not a safety issue.

[dtolnay]

@cramertj regarding remaining blockers, I would consider the behavior that @Boiethios reported above needs to be fixed before stabilization. I filed #54901 to follow up.