Hacker News Reader

Comment by Yoric | Hacker News Reader

Out of curiosity, what's the difference between virtual threads, green threads and, say, goroutines?

Not a lot. To a large extent, they are different names for the same concept. But since they are the names used for that concept by specific implementations, they also imply the particularities of those implementations.

The old Java green threads could only use a single core, the new Java virtual threads can use multiple cores. AFAIK, Java green and virtual threads are both cooperatively scheduled, Goroutines are, nowadays, preemptively scheduled. And so on and so forth.

Java's virtual threads are preemptive, not cooperative -- they are preempted not at explicit points, but at blocking IO operations.

If you can’t break a thread out of an infinite loop, that is pure cpu and no io, then the run time is not preemptive, surely??

At worst the OS will preempt the thread and the JVM will likely schedule a different virt thread the next time — but in case you have multiple CPU-hungry virtual threads fighting over a single core it will suck no matter what. The performance improvement comes from doing useful work on a thread during IO waits.

Nonetheless, there were discussions about some way to force preemption at certain points, not sure whether there is a decision since, but that will be the exception, not the rule.

Still trying to understand: what's the difference between "forc[ing] preemption" and cooperative threading?

In cooperative threading, a thread can only be suspended when it interacts with the runtime - so when it does I/O, or yields, or uses a lock, or maybe does some reflection, or perhaps allocates, or whatever. In preemptive threading, a thread can be suspended anywhere.

There is a bit of a grey area in between, where threads can be suspended outside the runtime, but not anywhere. Go had this for a while - threads could get suspended on function entry too.

If you've got a thread that's in a loop in which it doesn't allocate, doesn't call other functions, doesn't interact with the runtime in any way, maybe it's just looping over huge arrays of numbers doing calculations, then a cooperative threading runtime can't suspend it, whereas a preemptive threading runtime can.

But we're talking about forcing preemption, which is basically calling into the runtime, isn't it?

The terminology you're using doesn't really make sense to me, so i don't understand what you're asking, i'm afraid.

In cooperative multithreading, a thread only enters the runtime when that is part of its normal program flow. The code it's executing does I/O, or acquires a lock, or something like that. In preemptive multithreading, some mechanism can force any thread into the thread scheduler at any time.

If you climb back the chain, you'll see

> Nonetheless, there were discussions about some way to force preemption at certain points, not sure whether there is a decision since, but that will be the exception, not the rule.

I'm trying to understand the difference between "forcing preemption" and requesting for the runtime to yield, the latter being an operation typical in cooperative multithreading.

> they are preempted not at explicit points, but at blocking IO operations.

That is cooperative scheduling.

Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-blocking I/O that look and behave almost exactly the same, but are multiplexed onto fewer underlying OS threads, without needing to introduce language constructs such as async/await or changing anything in your program code except maybe the executor implementation.

Golang is opinionated towards its single coroutine model, there is no way to switch. Its a good model and it works well, but there are cases where it leaks, such as low-performance C interop.

Green threads usually refer to single-threaded runtimes such as Node.

So it's basically an implementation of transparent of M:N scheduling, right?

I remember that early versions of Rust had that but dropped it because building a single implementation of that that scales to all platforms is hard (tm).

Yep, M:N cooperatively scheduled. It also requires a "runtime" which Rust didn't want to have

Green threads usually refer to single-threaded runtimes such as Node.

This doesn't sound right. How is the single-threaded event-loop of node green threads?

Apart from that, it makes a lot of sense to have multiple threads in Node. They just run in the background, do stuff, and send events into JS land from time to time.

You're right, that was a bad example.

Reply on news.ycombinator.com