I suspect assumptions made by unsafe and C code
could get broken by cooperative multi-threading
unless each co-routine has its own TLS
and thus its own copy of thread-local variables
Logical assumptions made by safe code may get broken too if more than a single co-routine has access to a thread-local variable. Suppose some library is using this mechanism to pass "hidden" parameters to functions for example..
I suppose it's same as for stackless co-routines.
It's nice to be able to schedule a task on any OS-level thread from a pool
rather than just on a single fixed OS-level thread.
==
So it seems there are two considerations here
- when a stackful co-routine moves to a different executing OS-level thread (in a pool) it's nice to take thread-locals with it
- when multiple stackful co-routines share the same executing OS-level thread it's nice if each has its own private copy of thread-local variables - there may be logical assumptions relying on this in both safe and unsafe code and in libraries written in C
It seems rather appealing to be able to switch TLS at will and a library doing that might be a useful companion to libpthread both within and outside of Rust.