Hacker News Reader

Comment by dwattttt | Hacker News Reader

I'm curious; using hardware threads is M logical threads preemptively scheduled on N physical cores. In what way does this not satisfy the original criteria?

View on HN

They are still full OS threads: they have a full-size stack and have all the same overheads for context switching. Why would you think that a marketing term for a CPU feature is equivalent to an M:N scheduler?

A "hyperthread" can schedule work for two OS threads simultaneously on a single core. An M:N scheduler will schedule millions of green threads on as many cores/hardware threads as you give it (typically you'd give it all of them).

Yes. However the number of times I've scheduled millions of concurrent tasks is 0; hence my question about subjective experience.

I would guess that how well integrated OS threads or green threads are into a language has a much stronger impact on experience & quality.

EDIT: you're also comparing hyper threading itself to the green thread scheduler (M green threads vs 2 logical cores), that doesn't make any sense. You probably want to compare to the OS's scheduler. It will schedule those millions of threads over all the hardware concurrency available too.

That's just not what is referred to as green threads.

Yes, in implementation they are not. I'm curious what the difference in subjective experience is.

Green threads don’t allocate stack frames and do not require such a massive context switch, which in turn allows for many more threads.

But if you happen to call a blocking syscall everything breaks.

That's why higher level languages are in an advantage. E.g. in java - outside of FFI - syscalls are basically "only within" standard library functions. So it was possible to make them virtual thread aware, e.g. park a virt thread, use something like io uring for the actual IO call on the JVM level and resume it when it returns, doing work on another virt thread in the meanwhile.

That is not true of preemptive green threading systems. Go/Erlang/Haskell all run native foreign code on its own threads, and manage all internal I/O with async schedulers that never block. They also preempt user code in tight loops.

Those are the only mature languages that have all of these features.

Not sure if purposefully but you left out java. It doesn't preempt a CPU hot loop, but arguably you don't really want to disturb the CPU there / the whole "green thread" model doesn't make much sense with that kind of workload. That's why you have ordinary threads as well.

Reply on news.ycombinator.com