having "CLS" would actually be cool
you're right
it would solve dumb shit like that
but how do you make access to it fast?
if you allocate a CLS slab for every coroutine you defeat the purpose of allocating stuff on the stack of the coroutine in the first place...
I feel like we shouldn't solve the issue of TLS
if we did that we would severely hinder performance
instead we should work on making all libraries which make use of TLS coroutine compatible
for instance by removing TLS from libpanic
then triggers a coro switch
coroutine local storage is required for some usecase, i think it is fine
we can, for example, cache that CLS table after coroutine is destroied
so we won't need to allocate that table everytime
many optimization methods could be adopted in here
my first thought was:
keep a max() of the size of all previous CLS tables
whenever we create a coroutine we allocate that size for the CLS table on the stack
and if a new entry is added outside of that table we create a dynamically sized copy
or:
we figure out how to register all CLS macros before even main() is called
in C++ you can do that using static constructors
in C and LLVM you can write:
__attribute__((constructor)) void initializer() { ... }
if we can do the same in Rust we could indeed build fast CLS access
because we are modifying libstd
you have to still actually FIND all CLS macros ;)
and how do you do that without those constructors?
that's a problem
but won't push unless i have any significant changes
BTW: alexcrichton's futures library seems to be interesting
hmm? give me a link
i feel like its a lot harder to understand than my futures code though
I've read it for 10-15min and didnt get it
or why he uses that scheduler() method