[heartofgold]

For any older java programmers that may have a bad taste in their mouth when they think of green threads: when Java first came out, it had green threads, and all N threads that were spawned were tied to a single kernel thread. It also required cooperative multithreading, where one green thread may need to yield.

Java upgraded to native threads, and then you could have N java threads bound to N kernel threads. This was way better, but had downsides: You're limited on how many threads you can spawn, you need a threadpool to help manage, and any long-running tasks could effectively deplete your thread-pool.

With Loom, now you have M green threads mapped to N kernel threads. These green threads are way cheaper to spawn, so you could have thousands (millions even?) of green threads. Blocking calls won't tie up a kernel thread. So if you have many long-running IO tasks, they aren't going to waste a kernel thread and have it sit around idle waiting on IO. This is similar to async libraries, but without the mental overhead. You should be able to just code synchronously and the JVM will take care of the rest.

[ackfoobar]

> all N threads that were spawned were tied to a single kernel thread. It also required cooperative multithreading, where one green thread may need to yield.

This is pretty much how JavaScript operates. You can consider calling an async function as spawning a user-level "thread"; chained-up callbacks are the same thing, but with manual CPS transform.

This has always perplexed me. Why N:1 threading is hated, but Node.JS is so loved?

[kaba0]

You can still introduce very hard to debug blocking operations in nodejs, which will cause the whole runtime to slow down.

[_ZeD_]

no.

javascript has exactly 1 thread (with the exception of web workers, but they are a pain to use)

the whole idea is to not have to relies on "async" stuff.

[ackfoobar]

>> single kernel thread

> This is pretty much how JavaScript operates

> javascript has exactly 1 thread

No disagreement here. I understand what you are saying. Would be great if you had tried to understand what I said.

Maybe my explanation is lacking. Let me quote pron.

> Again, threads — at least in this context — [...] refer only to the abstraction allowing programmers to write sequences of code that can run and pause.

https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.ht...

An kernel thread running code line-by-line is a "thread"; callbacks that are sequenced (and have the dreaded pyramid indentation hell) forms a "thread"; when an async function is called there is also a "thread".

In JavaScript the latter two kinds of "threads" are run by one single kernel thread, i.e. N:1 threading.

[_ZeD_]

No. Callbacks are not a form of threads. Async is not a form of threads.

[ackfoobar]

If you take the word "thread" to mean only "OS thread", then of course you are right, in the most boring way.

If you agree that Project Loom virtual threads are threads, consider this. When pluggable executor is available, you start a few of virtual threads, confining them in the UI thread. Semantically, how are they different from calling async functions in JavaScript?

---

>> abstraction allowing programmers to write sequences of code that can run and pause.

> No. Callbacks are not a form of threads. Async is not a form of threads.

Simply a "No" adds nothing to the conversation. Do you not see that they are "sequences of code that can run and pause"? Or do you not agree with the wider meaning of the word "thread"?