< elizarov> Watching <https www youtube com watch v=nKJbDYRs kotlinlang #coroutines

, 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?

Another thing that puzzles me is that fibers seems to be implicit (no

suspend

keyword) and that it seems we don't care about blocking fibers. So I am wondering where is the trap ...

Vsevolod Tolstopyatov [JB]

10/24/2018, 11:20 AM

The 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

that it seems we don’t care about blocking fibers

once you own the whole runtime, you can intercept all blocking methods and suspend implicitly 🙂

sdeleuze

10/24/2018, 12:03 PM

Make sense, thanks for the feedback.

elizarov

10/24/2018, 2:40 PM

Let 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.

If (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

Whether 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

#coroutines Join Slack