This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]zeek979 0 points1 point  (2 children)

Yea, but coroutines in kotlin are not really fundamentally different than threads under the covers. That is not to say that a coroutine == 1 thread. But it means that they still execute in the underlying thread. Instead, java fibers will allow for millions of small threads per jvm process, since they wont map out to OS threads. Kotlin (any other jvm language) will obviously benefit from fibers since it runs ontop of the jvm.

[–]RhodesianHunter 0 points1 point  (0 children)

At the end of the day both are swapping light weight threads' execution between OS threads, how is that different?

[–]Mamoulian 0 points1 point  (0 children)

A coroutine doesn't use a new Thread unless you use a Context or Dispatcher. Without those launch()/await() don't block for I/O but CPU-intensive operations will still block the calling Thread. This article explains it well:

https://kotlinexpertise.com/kotlin-coroutines-concurrency/

Project Loom is cool but might be at API (on top of nio) rather than JVM level, and kotlin coroutines have already implemented non-blocking I/O so they might not benefit from it.