The existing libgreen will be moved out to a Cargo library. You just won't be able to seamlessly switch between the two like you did before, you'll have to explicitly use the green threading API instead.
How will this work if you depend on a lib that uses traditional threading but want to use green threads yourself? That actually comes up a lot at my work.
You'd have to use one that uses green threads internally.
Basically, in the effort to make the abstraction Just Work between 1:1 and N:M threading, we made green threads so heavyweight that they barely even qualified as green anymore. It's only by removing that abstraction that we could feasibly make them lightweight again.
The current implementation that's being phased out was designed to abstract away the threading model such that libraries could make use of concurrency while the programs that use those libraries could use any threading model they choose, and it would all Just Work. However, in practice this caused too many compromises in the implementation of both the native thread runtime and the green thread runtime, erasing the benefits of both.
Sorry! We're sensitive to your use case, but we just couldn't make it work.
No, and we actually use a "tasklet" library in Servo for the really fine-grained parallelism (per-CSS-block) where any allocation on task spawn would be far too expensive and work stealing is essential.
Could you point me to this? I did a cursory look through the Servo codebase. It just occurred to me that since Servo is pretty much the reason for the existence of Rust, it is probably the best thing to learn Rust by reading code.
I have had a problem learning Rust by example, the codebases I would like to read don't usually work with the latest Rust releases.
I don't really _do_ C++, but if I could talk to Rust from C++ maybe I could start hacking on their codebases.
