> you can access TLS and it will cause UB, in purely safe code. Errrk. I was looking at using it (because async really does suck from a usability point of vie

> you can access TLS and it will cause UB, in purely safe code. Errrk. I was looking at using it (because async really does suck from a usability point of view compared to green threads). Do you have a link? Hmmm. Is it TLS consuming too much stack? https://github.com/rust-lang/rust/issues/111272 https://github.com/rust-lang/rust/issues/111272 That would be an issue for green threads. And other things, as I discovered when I took a brief look at the may code to see if they handled stack allocation. Turns out may doesn't don't handle it directly - the standard library (nightly) has a way of creating stacks for co-routines (generator::Gn). May's green threads are just co-routines, and the Rust nighly library provides the stack. That means if it is the issue I linked to, it's a bit unfair to blame it on may. The same bug will manifest itself any Rust nightly generator that calls TLS. Probing further, it generator::Gn creates using stack::Stack, and stack::Stack allocates stacks using malloc. And yes, that guarantees stack overflow will cause UB of the worst sort because it just overwrite the next malloced block. Someone should lookup "man 5 mmap" on Linux and BSD. Both have ways that create stacks behave very nicely, including causing a hard fail if they overflow rather than UB. I presume Windows has a similar function. To repeat the point I keep making: all these issues with green threads aren't intrinsic issues to the concept. They arise because the initial Rust implementation wasn't well designed, and not implemented particularly well either.