#rust-lang

woboats, Zoxc: found one minor issue with self-borrowing generators heh

[Issue 49682] <open> Keeping references to #[thread_local] statics is allowed across yields. <https://github.com/rust-lang/rust/issues/49682>;

Does borrowing a #[thread_local] return 'static references or some local lifetime for each use?

Either way, it seems fixable by banning borrows from thread_locals across yields?

Zoxc: it's local

and yeah I think there's a straightforward solution

Zoxc: I only came across it because someone mentioned stackful coroutines and TLS elsewhere :P

and I thought that the generator state transform would prevent misuse because it can see the reference, but specifically self-borrowing generators assume it's just another stack local :P

eddyb: how serious is the thread local problem

sounds like you think its easy to fix?

woboats: the conceptual fix is easy, idk what the code looks like

woboats: the problem is not *too* serious because #[thread_local] will likely not be stabilized any time soon

and we can just literally block its stabilization on fixing this etc.

eddyb: what about the reply about an external library providing some thread local mechanism?

does it not apply to that crate because its API doesnt work like #[thread_local]?

#[thread_local] has borrowck magic

Zoxc: I assume by implication the third party crate does not?

I'll be impressed if stable crates alter borrowck =P

well as long as the unsoundness doesnt apply to stable it is not a huge priority :)

I don't think the addition of immovable generators makes already sound stable crates unsound, you can still have unsound stable code using unsafe though

woboats: they don't have access to the hack #[thread_local] has, so they're either unsound already or they're fine

hmmmm

you could call https://amanieu.github.io/thread_local-rs/threa...

and keep the result

then move the generator to another thread

Zoxc, woboats: wait what this looks very... uuhhh

Amanieu: what owns these values?

eddyb: which values?

the thread-local values are dropped when the ThreadLocal is dropped

eddyb: That seems fine to me. ThreadLocal is basicially just a HashMap<ThreadId, Value>

not when the thread exits

in fact, a new thread can access the value of a dead thread if it reuses the same thread ID

Zoxc: yes it's basically a lock-free hashmap

Amanieu: okay then it has no TLS issues

eddyb: well, not exactly. ThreadLocal allows you to store non-Sync data

so it could get nasty if a reference escapes to another thread

*a reference returned by get()

i thought that too but &NonSync isn't Send

that's fine, the problem is use-after-free with Sync/Send data

ThreadLocal by design doesn't ever delete entries from the HashMap, since this allows faster lookup (no need for memory barriers)

eddyb nrc : lang mtg

crap DST changed here while I was away and now the meeting is an hour earlier, so I was asleep. Sorry

whatever happened to reem?

feel like we've not heard from them lately

cramertj: best crate name ever ;)

nmatsakis: unfortunately I got pretty busy with other stuff in life but I still watch all the progress going on with rust with great joy :)

=) good to hear

hoping one day in the nearish future I'll be able to get more into it if I can find good use cases at work

was going to launch this https://github.com/terminalcloud/tfs a while back but terminal got acquired by udacity and that project got abandoned

reem_: Would you by any chance like co-maintainers or new maintainers for any of your Rust crates?

reem_: There are some used in Firefox/Servo that we'd love to be able to make minor updates to without forking.