I don’t know it very well, but as far as I understand the concept, it is even simpler. We don’t need
withContext(Dispatechers.IO), because we can call the “blocking” code as normal.
Main thread is an interesting problem though, @fvasco mentioned it already. I assume it should be possible to run an executor with parallelism=1, maybe even assign it to a single physical thread, and it would provide a similar functionality, but there are still 2 problems:
- The main idea behind event loops is that we can mutate the shared state freely, events are guaranteed to be handled fully before picking up the next one, etc. This is still partially valid in Kotlin, because coroutines are scheduled cooperatively, so as long as we don’t suspend, we keep the same benefits. With preemtive scheduling, we lose main advantages of using event loops. Does Loom allow to selectively switch to cooperative scheduling?
- Kotlin couroutines could easily wrap an existing implementation of an event loop, which doesn’t know about Kotlin. This is possible because suspending is implemented by returning. It is hard for me to imagine how could it possibly work with Loom. But maybe they already solved this problem somehow.
The above code shouldn’t be a problem, I don’t see a reason why it wouldn’t be possible with Loom. Problem may happen if we need to suspend inside the main thread.