I just had a thought. If I run coroutines on a JVM...

# coroutines

[Jason Zhao]

I just had a thought. If I run coroutines on a JVM supporting Loom, is there any reason not to use a virtual threads-based analogue to <http://Dispatchers.IO|Dispatchers.IO> everywhere you would normally use Dispatchers.Default?

Of course, normally doing this would have no benefit (but likely no drawbacks either?) other than making sure that you no longer need to care about the distinction between IO and Main dispatchers. However, doing this would also allow combining blocking with non-blocking operations to do some pretty unique and cool stuff, essentially using suspends as a way to explicitly switch context.

For example I can use a coroutine context with limitedParallelism(1) to encompass some resource (e.g. a Player in a game project) that contains a lot of data and logic. This data is all non-synchronized in order to make it more maintainable and have less overhead (think a Node.JS event loop).

So, if I use a Loom IO dispatcher, I think I shouldn't be afraid of blocking the coroutine at all. If during the logic, I need to wait for something but don't want the data in my object to change from other coroutines while I wait, then I can choose to block (e.g. via runBlocking). If I need to wait but don't mind the data changing in the process, then I can choose to suspend, and let other coroutines run on my limitedParallelism context. So I can always get the best level of concurrency depending on what behavior I expect in my code.

[Sam]

Roman did a good talk on this at KotlinConf. He suggested that the default coroutine dispatcher will still be more performant than a virtual-thread-per-task dispatcher for normal work, because it's optimized to avoid thread switching. You can find the video on YouTube.

[Sam]

Here's the relevant part:

https://youtu.be/zluKcazgkV4?t=2379▾

[Riccardo Lippolis]

See also the implementation note in the documentation for `Dispatchers.IO`: https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-i-o.html

[Jason Zhao]

Wouldn't virtual thread IO-style dispatcher still try to share threads and avoid switching though?

[Riccardo Lippolis]

Virtual Threads always run on different threads (called 'carrier threads') than non-virtual threads (platform threads), so switching from Dispatchers.Default to a Dispatcher using Virtual Threads would always involve a thread context switch.

If you'd just run all coroutines on a Virtual Thread dispatcher, the dispatcher would just spawn a new Virtual Thread for every coroutine started (because the dispatcher schedules it using an Executor that just creates a new one for each task that gets submitted), and the coroutine might or might not run fully on a single carrier thread, probably depending on whether it will actually suspend (but the key thing here is: you shouldn't depend on it 😅)