Hacker News Reader

Comment by vmfunction | Hacker News Reader

what about "green threads" that is not managed by the OS like https://tokio.rs ?

Tokio is using the Rust async features, which are not green threads. In the former code has to explicitly mark potential yield points, in the latter green threads can be scheduled by the runtime without any help from the code itself.

As a historical note, Rust used to have green threads but they were abandoned a long time ago. This is a good talk about both the differences between different forms of concurrency/async and Rusts history with them: https://www.infoq.com/presentations/rust-2019/ (includes a transcript)

I believe these green threads work well when there’s good support in both language, runtime and standard library. I have built complicated concurrent software in C# with async-await. I don’t program golang but I heard the concurrency model works rather well in golang too, probably for the same reason as C#: good support in the language and the runtime.

I have no idea about Tokyo. I don’t program Rust, and the feedback I read about async/await was mixed.

You only ever need this if you're trying to have hundreds of thousands to millions of threads. It's a very niche problem to have

It's a niche problem to have because our current programming paradigm treats concurrency as a second-class citizen. The invariants of most languages do not include those required for mass concurrency.

Functional programming better aligns with the requirements, which is how you arrive at Erlang and Elixir. Every map() function can be trivially replaced with the concurrent cmap(), because the side effects that would make it non-trivial are impossible to express.

Given that Moore's law as it applied to single threaded performance is dead and in the ground, it makes a lot of sense to start paying more attention to systems that treat concurrency as more than an afterthought.

Except in that scenario you absolutely don't want green threads but real threads. M:N threading (especially if N=1) doesn't help you get parallelism, and parallelism is what you need for modern CPUs.

So that again keeps green threads (and thus mass concurrency without parallelism) in the niche category.

Green threads do not make use of multiple cores of a modern processor.

It's entirely possible for a green threads implementation to schedule the green threads over multiple OS threads, thus making use of multiple cores. The programming language "Go" being a popular implementation of this.

M:N green threads run M green threads on N OS threads and thus use up to N processor cores

what makes you say this?

go programs definitely saturate modern server-class CPUs

Reply on news.ycombinator.com