Is

runBlocking

an expensive operation? The docs seem to suggest that it’s a good idea to use it once in the main-method and than stay in suspend-country for the rest of the codebase. But how about sprinkling in a bit of concurrent computation here and there with snippets like this:

val (a, b) = runBlocking(Dispatchers.Default) {
        val aDeferred = async {getA()}
        val aDeferred = async {getB()}
        return@runBlocking aDeferred.await() to bDeferred.await()
}

Doable or bad idea?

the overhead is pretty small, but it does block the thread

sounds like “doable” then 🙂

I would also removed default dispatcher, it’s not really necessary there

It makes getA and getB run parallel though?

depends on how a and b are implemented

apparently, if those a and b are proper suspend functions they will run in parallel

I don't think

getA()

or

getB()

being suspend function affects them executing in parallel in this case. As far as I understand it, it will depend on the dispatcher.

if function is proper suspend function, so it doesn’t block the thread, they will run in parallel, with any dispatcher (except some non-existing, which limits amount of coroutines in paralell)

actually, if you were to drop the

Dispatchers.Default

, they would run concurrently but not in parallel, because there is only one thread for

runBlocking

not necessary, it depends on getA() and getB implementation

I think you have a misunderstanding of the term 'parallel' -- it means that code is executing at the same time, which

delay

does not represent, no code is executed while the delay is happening (i.e., no CPU usage). using

delay

represents a concurrent process. take for example Javascript, nothing is ever done in parallel with javascript, it is all one single-threaded event loop. that is what I mean by

runBlocking

(with no specified dispatcher) being concurrent but not parallel

I know what is parallel

right, but that introduces a new dispatcher, I am specifically talking if you didn't add the I/O dispatcher

With any dispatcher in runBlocking they will run in parallel

that is true, but I want to be clear that it requires them to use a different dispatcher

or if they are asyncronous, right?

this code demonstrates the issue:

fun main() {
    runBlocking {
        val a = async {
            println("Computing [A]...")
            // be blocking
            Thread.sleep(1000)
            println("Finish [A]!")
            100
        }
        val b = async {
            println("Computing [B]...")
            // be blocking
            Thread.sleep(1000)
            println("Finish [B]!")
            200
        }
        println("Technically concurrent! I can execute with those queued up.")
        println(a.await() + b.await())
    }
}

both computations are not done in parallel, though they are both done concurrently, i.e. it does not stop you from setting up the code to execute later obviously, just using

Dispatchers.Default

here is enough to alleviate the problem

I mentioned this problem in my first message, it will run in parallel only if functions are not blocking

right, but all code at some level is blocking, it's just for how long

Dispatchers.Default will solve it, I agree, but I would say that it’s bad pattern

I am kinda talking about practical usage here -- even some operations on non-IO become sufficiently blocking that their performance is measurable. I worked out this example of sorting large lists: https://gist.github.com/octylFractal/5443dc85fbf3673553f30f68fa888f21

But this operation is blocking

yes, that's what I'm getting at

so you should wrap this chunk to Dispatcher.Default

right, but not everyone does that

this chunk, not expect that some user of this API will do this for you

I'm just saying be aware of how things are implemented

maybe introducing bad pattern to fix another bad code is fine

yes, certainly

so you should wrap this chunk to Dispatcher.Default

I did not know that was best practice, switching dispatcher close to the expensive code itself.

I would think it is, if you're already on the dispatcher it's nearly free

if you do not wrap some heavy code to own dispatcher, it may cause issues for consumer

basically, I just want people to be aware of the fact that the event loop does not run anything in parallel -- if you delegate to another dispatcher, then it can await the results from said dispatcher concurrently but the event loop itself is not parallel-capable

This is the gist of it. I think it's also important to be aware of what your default dispatcher is especially in multi platform environment, because on JVM it's backed by a thread pool, so you will get parallel execution, but on JS (always single-thread) and Native (uses SingleThreadDispatcher at least in 1.3.5-native-mt-1.4M1) you will get concurrent but not parallel execution.

Likewise if using

kotlinx-coroutines-android

you will find that

Dispatchers.Main

is backed by a

Handler

using

Looper.getMainLooper()

, which is another example of a single-threaded event loop. This same logic also applies to dispatchers based on a single-threaded Executor. The lack of parallel execution in these cases is one of the reasons you can use thread confinement to safely mutate shared state without need for other synchronization mechanisms.