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.
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?
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.
> 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.
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"?