> We are removing support for green threading from the standard library and moving it out into an external package. This allows for a closer match between the Rust model and the underlying operating system, which makes for more efficient programs.
That's an interesting move in comparison to Go, which multiplexes coroutines onto threads.
It's more systems-like. We don't pay any overhead for calling into C code, and M:N scheduling doesn't really provide advantages over 1:1 scheduling when you don't have a GC (and even when you do, the differences are fairly negligible on modern Linux).
With 1:1 scheduling, how do you limit stack size to something reasonable (a few kB per thread), which is necessary when you need to launch tens of thousands of threads?
Thanks for the link. But what if I don't know the stack size in advance? I guess the model with a stack that starts small and grows on demand is only possible with M:N scheduling, not with 1:1 native scheduling?
That's an interesting move in comparison to Go, which multiplexes coroutines onto threads.