at time 20:23, the when the lambda is running the suuplyAsync(), some thread from the pool will be blocked right? I don't think the thread that launches this lambda will be freed up to do other tasks before the lambda returns. Hence this will still not be able to launch a million requests. In other word, this is still a 1 blocking request per thread pattern
WeatherReader::getBodyFrom is blocking call, so a completable future will block. httpClient.sendAsync must be used with .thenComposeAsync (or .thenCompose) Kinda a huge mistake in async programming An it's at 18:19
Hi @IntelliJ IDEA, a JetBrains IDE, I want to understand the following - 1. How is it ensured that all the blocking operations invoked by any arbitrary code (excluding native method calls and synchronized blocks) from a virtual thread are managed by the Continuation framework? Have all the potential blocking points in the JDK been identified and adapted to support this? 2. Consider a third-party library that is confirmed not to use native methods or synchronized blocks. While calling it from a virtual thread, is it still necessary to manually verify that it will not accidentally block the underlying platform thread? Thanks.
CompletableFeature in that case just transfer bloking problem from main thread to tread's pool thread. and really getting situation even worse since you have limited theads in pool and it preventing you to schedule to another thread to make something usefule you like forcing your CPU do deal with "waiting" tasks
One more question, if possible. How will virtual thread deal with happens before guarantee? Since context switching will be so much faster, will the compiler need to rearrange code, creating visibility issues?
It is so cringing when I hear Kotlin trying to sell it does something than Java when the entire life cycle of Kotlin is running on JVM. Kotlin is only useful for code simplicity like Lamda not in anyway performant than Java.
@@encapsulatio 1. Coroutines let you clearly define what's suspending or not, not some magic blocking functions by JDK that are special. 2. Coroutines have context which allows you to carry around a lot of useful information. 3. Coroutine jobs and cancellation mechanics that cascade to other subroutines. with that said from some basic tests loom is actually faster than coroutines
@@GafarOlanipekun Kotlin does not just run on JVM... and why that even matters, kotlin is simply a better language that forced java team to actually care about their language. They keep releasing features that we had like 10 years ago, with a lag. What stopped them from doing these things before? if they did there would be no need for kotlin
I am a simple Java developer, whenever I see a video with Jose, I like it. 1:14:41
Thanks!
he's the European Venkat :)
Whenever I see his simple, sincere face, I immediately feel the urge to code something concurrent.
This guy is awesome. I like the way he easily explains difficult concepts. @Jose is s a Lengend!
This was a great format! I wish I had watch it live.
Nice. Thx for the video and your contribution to the community
Great video! 🎉
Truly professor explanation😊
good detailed presentation, thanks. internals, guts of the things are especially interesting
This reminds me of generator functions in Python; great explanation
Amazing session!
Awesome feature!
Awesome LTS version
at time 20:23, the when the lambda is running the suuplyAsync(), some thread from the pool will be blocked right? I don't think the thread that launches this lambda will be freed up to do other tasks before the lambda returns. Hence this will still not be able to launch a million requests. In other word, this is still a 1 blocking request per thread pattern
WeatherReader::getBodyFrom is blocking call, so a completable future will block.
httpClient.sendAsync must be used with .thenComposeAsync (or .thenCompose)
Kinda a huge mistake in async programming
An it's at 18:19
Hi @IntelliJ IDEA, a JetBrains IDE, I want to understand the following -
1. How is it ensured that all the blocking operations invoked by any arbitrary code (excluding native method calls and synchronized blocks) from a virtual thread are managed by the Continuation framework? Have all the potential blocking points in the JDK been identified and adapted to support this?
2. Consider a third-party library that is confirmed not to use native methods or synchronized blocks. While calling it from a virtual thread, is it still necessary to manually verify that it will not accidentally block the underlying platform thread?
Thanks.
Révolution!!!!
@Mala you wanted to attach his GitHub link btw
CompletableFeature in that case just transfer bloking problem from main thread to tread's pool thread. and really getting situation even worse since you have limited theads in pool and it preventing you to schedule to another thread to make something usefule you like forcing your CPU do deal with "waiting" tasks
One more question, if possible. How will virtual thread deal with happens before guarantee? Since context switching will be so much faster, will the compiler need to rearrange code, creating visibility issues?
Can anyone point me to a HttpClient library that supports virtual threads? Does spring's webclient / apache HttpComponents support them?
This is in many ways inferior to coroutines in kotlin
but still a huge step for java, nice job.
What are the "many ways"? List them please.
No
It is so cringing when I hear Kotlin trying to sell it does something than Java when the entire life cycle of Kotlin is running on JVM. Kotlin is only useful for code simplicity like Lamda not in anyway performant than Java.
@@encapsulatio 1. Coroutines let you clearly define what's suspending or not, not some magic blocking functions by JDK that are special.
2. Coroutines have context which allows you to carry around a lot of useful information.
3. Coroutine jobs and cancellation mechanics that cascade to other subroutines.
with that said from some basic tests loom is actually faster than coroutines
@@GafarOlanipekun Kotlin does not just run on JVM... and why that even matters, kotlin is simply a better language that forced java team to actually care about their language. They keep releasing features that we had like 10 years ago, with a lag. What stopped them from doing these things before? if they did there would be no need for kotlin