probably a dumb question but... when you submit something to a pool of threads like a ForkJoinPool, you are actually creating a "Task" which is going to be queued and handled by a thread when available, so in practice I don't see any advantage of using virtual threads since the "task" should be already lightweight, and the blocking should be also semantic, you don't block the thread of a pool, you just block a task. So long I don't use Java that when you wrote "var" I thought you were confusing Scala with Java xD update: now I saw that you showed that virtual threads are implemented with a fork join pool o_O so anything that can be implemented with virtual threads can be imlemented with a fork join pool with essentially the same behaviour and semantics in older version of java... is that correct.
It's not just the fork-join pool, it's the main Thread API that is now lightweight. This is subtle, but game-changing: for example, you can use blocking calls with the main Thread API (which used to be bad practice) and it's totally fine.
Jvm will unload task(virtual thread) when it meet some blocking call (not all kinds are supported currently e.g. sychronized block), while in the past, those blocking calls would block the theads of thread pool
It's because your assumption: ""task" should be already lightweight, and the blocking should be also semantic, you don't block the thread of a pool, you just block a task" is wrong. If you make an I/O call to a socket on a task for example, it WILL block the thread in your pool. Before Virtual Threads the only way to leverage non-blocking IO (i.e. those based on epoll, kqueue, iocp) was to leverage java.nio, and good luck with that. A "task" in Java is not the same conceptually as an async Task in C# or Swift or a promise in Javascript, all of which have non-blocking implementations. But with virtual threads we have that now!
this is not how it works this is "how to use it"... how it works would be : how does virtual thread carry around the stack, how does it work under the hood, how it identifies what is "blocking" etc etc...
It was great explanation about virtual threads.
This is a great primer!
This is really advances stuff. Do you intent to do a video that starts from Threads basics walking right up to advanced stuff like this?
maybe!
I feel bad for making 42 views into 43. Did I just change the meaningOfLife?
oh my bad, it's immutable :p
Awwwesome 🎉
probably a dumb question but... when you submit something to a pool of threads like a ForkJoinPool, you are actually creating a "Task" which is going to be queued and handled by a thread when available, so in practice I don't see any advantage of using virtual threads since the "task" should be already lightweight, and the blocking should be also semantic, you don't block the thread of a pool, you just block a task. So long I don't use Java that when you wrote "var" I thought you were confusing Scala with Java xD
update: now I saw that you showed that virtual threads are implemented with a fork join pool o_O
so anything that can be implemented with virtual threads can be imlemented with a fork join pool with essentially the same behaviour and semantics in older version of java... is that correct.
It's not just the fork-join pool, it's the main Thread API that is now lightweight. This is subtle, but game-changing: for example, you can use blocking calls with the main Thread API (which used to be bad practice) and it's totally fine.
Jvm will unload task(virtual thread) when it meet some blocking call (not all kinds are supported currently e.g. sychronized block), while in the past, those blocking calls would block the theads of thread pool
It's because your assumption: ""task" should be already lightweight, and the blocking should be also semantic, you don't block the thread of a pool, you just block a task" is wrong. If you make an I/O call to a socket on a task for example, it WILL block the thread in your pool. Before Virtual Threads the only way to leverage non-blocking IO (i.e. those based on epoll, kqueue, iocp) was to leverage java.nio, and good luck with that. A "task" in Java is not the same conceptually as an async Task in C# or Swift or a promise in Javascript, all of which have non-blocking implementations. But with virtual threads we have that now!
is Go and Rust Tokio channel equivalent available in Java VT?
Not quite - different mental model
Will there be a spring boot course? (it would be really interesting in the form of a full-fledged project with ui)
I think it is the same as a green thread/fiber in Cat Effects?
The goal and mechanics are similar, the API/thinking model is a bit different.
this is not how it works this is "how to use it"...
how it works would be : how does virtual thread carry around the stack, how does it work under the hood, how it identifies what is "blocking" etc etc...
I recon the point of having virtual threads is to not have a pool of them. You rather create a new VT for each task.
Not only. It looks like Kotlin coroutine and suspend function but now it is managed by JVM not Kotlin compiler.