aturon commented 8 years ago

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. macOS 10.6 didn'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.
[x] Statics that are thread local shouldn't require Sync - https://github.com/rust-lang/rust/issues/18001
[x] Statics that are thread local should either not borrow for the 'static lifetime or should be unsafe to access - https://github.com/rust-lang/rust/issues/17954
[x] Statics can currently reference other thread local statics, but this is a bug - https://github.com/rust-lang/rust/issues/18712
[ ] Unsound with generators https://github.com/rust-lang/rust/issues/49682
[ ] static mut can be given 'static lifetime with NLL (https://github.com/rust-lang/rust/issues/54366)

aturon commented 8 years ago

@alexcrichton Can you elaborate on the blockers?

alexcrichton commented 8 years ago

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 - https://github.com/rust-lang/rust/issues/18001
Statics that are thread local should either not borrow for the 'static lifetime or should be unsafe to access - https://github.com/rust-lang/rust/issues/17954
Statics can currently reference other thread local statics, but this is a bug - https://github.com/rust-lang/rust/issues/18712

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

alexcrichton commented 8 years ago

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 commented 8 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

mneumann commented 7 years ago

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

real-felix commented 7 years ago

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 commented 7 years ago

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

real-felix commented 7 years ago

It compiles with the last nightly rustc.

eddyb commented 7 years ago

Oh, drat, this is from my shortening of the lifetime, i.e https://github.com/rust-lang/rust/blob/dead08cb331343b84564628b139b657f93548320/src/librustc/middle/mem_categorization.rs#L657-L662 @nikomatsakis what should we do here? I want a static lvalue, with a non-'static lifetime.

cramertj commented 6 years ago

43746.

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

eddyb commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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

Amanieu commented 6 years ago

@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 commented 5 years ago

@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.

josephlr commented 5 years ago

Copying @gnzlbg's comment from https://github.com/rust-lang/libc/pull/1432

It appears that 1) thread_local! solves the problem for most people, and 2) the main uncertainty is that #[thread_local] isn't portable.

Maybe we could reduce the scope of an initial version of #[thread_local] to extern static declarations. If the target does not support #[thread_local], well then the extern static declaration is incorrect since there cannot be a definition anywhere, and using it would already be UB. We could add on top of this a "best effort" compilation error, e.g., if the compiler knows that the target doesn't support it.

I agree with the above, thread_local! and #[thread_local] for extern static unblocks virtually all use-cases, and would allow interfaces to errno using stable Rust on all platforms (see the linked libc issue for more context).

Right now there is no way (with stable Rust) to use C thread local variables via FFI without writing additional C glue code, see the errno-dragonfly crate for an example of such a (necessary) hack.

gnzlbg commented 5 years ago

cc @joshtriplett: allowing #[thread_local] on extern statics might be something for the agenda of the WG-FFI, since interfacing with errno is kind of an important part of the C FFI puzzle.

joshtriplett commented 5 years ago

@gnzlbg Thanks! Agreed, we definitely need thread-local-variable support.

cbiffle commented 4 years ago

Independent of the FFI need for extern static...

Like @Amanieu from last year, I'm using #[thread_local] in a no_std context (an RTOS, in my case), with the OS runtime handling management of the TLS pointer and memory. (They and I differ on one point, which is that I'm delighted that #[thread_local] lifts the Sync requirement for static. It seems good and right.)

#[thread_local] is currently the only unstable feature I have to rely on for program correctness. (I'm using a couple others for convenience, but I could lower them by hand if required. I cannot easily replicate the TLS link behavior by hand.)

I haven't dug into the compiler side of this, so this question may be naive, but is the has_elf_tls LLVM target feature not sufficient to gate this? We have a few other language features (if not attributes per se) that are gated by target support -- for example, my platform doesn't have AtomicU64. So it doesn't seem entirely without precedent.

tuxillo commented 4 years ago

@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).

We now provide __errno_location() since this commit:

https://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/60d311380ff2bf02a87700a0f3e6eb53e6034920

bstrie commented 4 years ago

The original issue suggests that the thread_local attribute in LLVM isn't supported across all platforms, but has platform support improved in the time since this issue was opened? Or do we expect that it will always remain nonportable? (Is there an LLVM tracking issue?)

nicbn commented 4 years ago

Hello, #[thread_local] can currently be applied to fields of a struct without any errors or warnings (it won't work oc):

#![feature(thread_local)]

use std::sync::{Arc, Mutex};

#[derive(Debug)]
struct Foo {
    #[thread_local]
    bar: &'static str,
}

fn main() {
    let foo = Arc::new(Mutex::new(Foo {
        bar: "bar",  
    }));

    dbg!(foo.lock().unwrap().bar);

    let foo2 = foo.clone();
    std::thread::spawn(move || {
        foo2.lock().unwrap().bar = "baz";
    }).join().unwrap();

    dbg!(foo.lock().unwrap().bar);
}

Outputs:

[src/main.rs:16] foo.lock().unwrap().bar = "bar"
[src/main.rs:23] foo.lock().unwrap().bar = "baz"