<@U2E974ELT> Watching <https://www.youtube.com/wat...
# coroutiness
sdeleuze
10/24/2018, 10:32 AM@elizarov Watching , I am wondering if in long term future (let say Java 17 LTS since there is now a release each 6 months) it would make sense to think about Coroutines that would run on fibers (1 coroutine = 1 fiber) on the JVM to improve monitoring, debuggability, maybe performances. Any thoughts?
sdeleuze
10/24/2018, 10:55 AMAnother thing that puzzles me is that fibers seems to be implicit (no
suspendv
Vsevolod Tolstopyatov [JB]
10/24/2018, 11:20 AMThe direction project Loom has taken is completely orthogonal to Kotlin coroutines.
Fibers are in a very early prototype and it is hard to judge how it will affect Kotlin coroutines and companion libraries. And from the previous major JDK features, I doubt we will see fibers in two or three years (and then there will be five years more until community and Android will adopt it 🙂)
👍 2
Vsevolod Tolstopyatov [JB]
10/24/2018, 11:21 AMthat it seems we don’t care about blocking fibersonce you own the whole runtime, you can intercept all blocking methods and suspend implicitly 🙂
s
sdeleuze
10/24/2018, 12:03 PMMake sense, thanks for the feedback.
e
elizarov
10/24/2018, 2:40 PMLet me also add the the technical challenge that the Project Loom’s team had set to solve is huge. I really doubt anything can come faster than in 2-3 years and even that it is not clear what it is going to be at the end.
elizarov
10/24/2018, 2:42 PMIf (big if) they really solve all the problems and make runtime to transparently understand all the blocking calls, then, at least, we would have an option of running our Dispatchers.IO pool on top of fibers, thus avoid using threads for blocking calls.
👍 2
elizarov
10/24/2018, 2:43 PMWhether this is going to be more performant than async-first API is questionable and yet to be seem in the future. It is going to be convenient, though, if they manage to pull it off
2 Views