Getting acquainted with Rust's mio
hoverbear.org
hoverbear.org
In the beginning, Rust had only green threads. This was because concurrency was deemed important, and everybody knows green threads are where it's at. (totally not sarcasm. Totally.)
Eventually, it was decided that a systems language without systems threads is... strange. So we needed to add them. Why not add choice? Since the interfaces could be the same, why not abstract over them, and you could just choose which one you wanted?
At the same time, the problems with green threads by default were becoming issues. Segmented stacks cause slow C interop. You need a runtime to manage them, etc.
Furthermore, the overall abstraction was causing an unacceptable cost. The green threads weren't very green. Plus, with the need to actually release someday looming, decisions needed to be made regarding tradeoffs. And since Rust is supposed to be a systems language, having 1:1 threads and basically no runtime makes more sense than N:M threads and a runtime. So libgreen was removed, the interface was re-done to be 1:1 thread centric, and Servo got mad. That's another story.
That doesn't mean that green threads are evil. Remember, I/O isn't a language thing, really, it's a library thing, in a language as low-level as Rust. In fact, that's one of the reasons green threads could be removed: libraries like mio could provide the benefits, without the problems that were being caused. Servo might also write a green threading library, with a different set of tradeoffs from mio's implementation.
Anyway, this is my pre-coffee explanation of the history. I'm being a bit silly, so please don't read into any particular bit of language here, that's just the high-level story.
Anyway, the article's introduced me to consensus algorithms, so thanks for that.
In any case, I'll be interested in seeing how it ends up getting used. It's nice to have it available.