Does runBlocking s block thread on suspend also apply to chi

Question

Does runBlocking s block thread on suspend also apply to child coroutines

Dominaezzz · Answer

You want `runBlocking` to block the calling thread until all the `launch`ed child coroutines finish

Sam · Answer

It already does that My question is to guarantee the sequence of child

Sam · Answer

```runBlocking launch delay 200 println first launch done launch delay 100 println second launch done ```

Dominaezzz · Answer

Oh you want to the first `launch` to finish before the second `launch`

Sam · Answer

yes

Sam · Answer

execute all in a sequence blocking on suspend calls irrespective of whether they are from same coroutine or child or further nested levels

bdawg.io · Answer

You would need to have the second one wait

Dominaezzz · Answer

Then why are you `launch`ing them `launch`ing means concurrency

Sam · Answer

yes in actual code but lets say in a testing code

bdawg.io · Answer

In which case as < Dominaezzz> just said is not concurrency so `launch` is just overhead at this point

Sam · Answer

or let me rephrase it ``` repeat 1000 runBlocking launch println first launch done launch println second launch done ```

Sam · Answer

the above launch doesn t have any delay and calling it under runBlocking 1000 or any number of times completes the first launch before the second one

Sam · Answer

Is that just a coincidence or working as design

Dominaezzz · Answer

Coincidence

Dominaezzz · Answer

It s just very very unlikely for the second launch to finish first in this case

Dominaezzz · Answer

But there s no documentation officially describing coroutine launch finish order

Sam · Answer

I thought so too but then i tried replacing runBlocking with a GlobalScope launch and a sleep i see the race

Sam · Answer

``` repeat 10 GlobalScope launch launch println first launch done launch println second launch done Thread sleep 100 ```

Sam · Answer

this time i see the race when i repeat it just 10 times

Sam · Answer

but i don t see that with runBlocking thats why i was curious

Sam · Answer

After looking at this i m questioning the coincidence of runBlocking ``` runBlocking launch var sum = 0 repeat 100 000 0000 sum += 1 println first launch sum $sum launch var sum = 0 repeat 10 sum += 1 println second launch sum $sum ```

Sam · Answer

first launch sum 1000000000 second launch sum 10

Dominaezzz · Answer

Curious

Sam · Answer

Yeah runBlocking for sure seems to influence the order ```runBlocking launch val time = measureTimeMillis BigInteger 3500 Random nextProbablePrime println first launch sum $time launch println second launch sum ```

Sam · Answer

first launch sum 9087 second launch sum

Sam · Answer

this is where i got into a rabbit hole when i replaced the lengthy operation in first launch with a suspend call to delay In that case second launch with no or less delay completes before the first one

bdawg.io · Answer

The problem seems to be trying to predict how a concurrency library manages tasks in parallel runBlocking depends on it s backing dispatcher event loop Do you get the same results by using ```runBlocking Dispatchers Default ```

Sam · Answer

With Dispatchers Default i get expected results

Sam · Answer

the task with less activity with or without usage of delay in both task completes first

bdawg.io · Answer

Using `GlobalScope launch` will give you a different result because it uses Dispatchers Default CommonPool to obtain additional threads which allows more of your concurrent jobs to execute in parallel

Sam · Answer

Gotcha

bdawg.io · Answer

So if you use `runBlocking` by itself it only has the current thread so your first launch goes first on that single thread until it completes or suspends which is why your 1 billion sum completes before the second starts there s no additional threads for the second job to go in parallel

Sam · Answer

and delay suspends the first launch causing the second one to execute

Sam · Answer

Thanks with that it makes sense

Sam · Answer

So in other words runBlocking when used by itself guarantees sequential order of child coroutines as long as none of them invoke any suspend functions

bdawg.io · Answer

There s no documented guarantee or contract that will be the case but base on observation of the current implementation that does occur +1

Sam · Answer

Got it

Sam · Answer

<https github com Kotlin kotlinx coroutines blob master docs basics md scope builder> does have the complex nested case

Sam · Answer

Yeah the nitty gritty is not at all obvious for newcomers

Daniel Tam · Answer

if you want the first launch to finish first every time then you can wrap it in a coroutineScope

Daniel Tam · Answer

or just `join` on it

pankajrai · Answer

launch and async are coroutine builder where these coroutines run in parallel In case you want to run them in sequence than use await method of async and pass LAZY as a constructor parameter to async coroutine builder

pankajrai · Answer

Do not use GlobalScope its like building a demon thread for better structured concurrency use some kind of scope like runBlocking is one such which limits the scope to a function call

pankajrai · Answer

runBlocking will block the thread until all it s child execution is done so it s not so good to use runBlocking while building Android apps

bdawg.io · Answer

I think the point of the OP was to understand the dispatching behavior while inside of a scope launched via `runBlocking`