Hi, Can some explain to me why:

runBlocking {
        launch {
            println("a1")
            runBlocking { delay(100) }
            println("b1")
        }

        launch {
            println("a2")
            runBlocking { delay(300) }
            println("b2")
        }
    }

displays a1 a2 b2 b1 - instead of a1 a2 b1 b2

I think this is due to the way the scheduling will work given that everything is executing on the same thread.

runBlocking

will schedule a coroutine using

CoroutineStart.DEFAULT

which is effectively "immediately" - meaning the coroutine scheduled last will execute first.

depends on your platform. I would guess, that everything is running on a single thread which is blocked by the first

runBlocking { delay

that happens to start. if this would be your `runBlocking { delay(300) }`then it blocks the second, shorter deelay from even starting

It looks like it would be racy, I assume that you're not using

runBlocking

inside a suspend function in real code?

The issue is that I do not control the code between a and b - it's provided by users (I'm writing a framework)

can’t your framework provide a callback based api or return a completable future instead of blocking

Thx, it provides some good insights. Coroutines can be tricky sometimes

launch(Dispatchers.Default)

wil solve your imediate problem. But is more like a band Aid here: https://play.kotlinlang.org/#eyJ2ZXJzaW9uIjoiMS4zLjQxIiwicGxhdGZvcm0iOiJqYXZhIiwiYXJncy[…]AgICAgcHJpbnRsbihcImIyXCIpXG4gICAgICAgIH1cbiAgICB9XG59In0=

because, it’s only one thread and delay will ‘yield’ it to the second launch

Why wouldn't it?

You guys lost me. What is "because it's only one thread"? And what "wouldn't it"?

I think the answer to the original question hasn't anything to do with threads... The output comes because of there are two coroutines being launched. a1 comes first, but before b1 comes it has to wait 100 ms, so a2 comes immediately after. For b2 then it has to wait 300ms, so in the meanwhile, b1 gets logged. Then after comes b2.

@Orhan Tozan But run blocking blocks the thread. So a single threaded dispatcher can not dispatch another coroutine while one is blocking it's only thread

It doesn’t block, it waits for the work to finish in the same scope. launch blocks are independent, runblocking inside the first launch won’t influence the second. Even if there is only one thread

@Orhan Tozan b1 should come first, then b2 as you say. But if you read the original question, this is not what the poster experienced.

My answer is explaining a1 a2 b1 b2

@myanmarking this is plain wrong. And if it where so, I'd be interested, why you expect b2 before b1

nvm. i read it wrong 😛

@Orhan Tozan @myanmarking so we all agree 🤣

are you sure the test as it is produces a1 a2 b2 b1

yes! the first inner runBlocking keeps the only thread of the dispatcher blocked from doing anything else.

runBlocking { delay(300) }

is basically like Thread.sleep(300)

how does it explain the output being a1 a2 b1 b2

It’s actualy much more interesting then I thought 🙂 multiple runBlocking on the same thread share an event loop. So they do not block the thread.

I think you are confused with the work ‘blocking’. RunBlocking blocks no threads

well, it obviously yields when it’s block terminates. But why? and what is it waiting for? In the original example, during the time 100ms..300ms all coroutines are suspended and for some reason the first runBlocking does not return yet to print

b1

not when block terminates. How do you explain the output of my sample, please tell me. it blocks no threads

yes, that’s what I wrote above. all runBlocking use thee same event queue. so you are right, the 2 coroutines scheduled by the 2 runBlocking actually execute concurrently. But in the original example you see that b1 is not executed at 100ms but waits until the second runBlocking also terminates. That’s why b1 prints only after b2 and that is unexpected

Well, the example is bad. If you have a single thread, and you want to bridge async non-coroutine code, why would you use two launches? It’s useless since you only have one thread and your code does not suspend

What an insight 😉 It’s true, but does not explain anything 😂 And the code does suspend in

delay

yes, the code does suspend in delay but the usage is wrong. You don’t use runBlock inside a suspend function afaik. Even lint flags you that. It defeats the purpose of suspending

@myanmarking I’m aware of that. As said above, the code between println is actually a method.invoke in my code. And what it does is not under my control

@Gilles Barbier to make your tests / demo independent of the somewhat surprising

runBlocking

behaviour, replace

runBlocking {delay(100)}

in your tests with

Thread.sleep(100)

method.invoke, is sync or async ? Edit: Actually, i do think it does not matter. You normally do not use runBlocking this way, it’s the other way around.

@uli then the output is a1 b1 a2 b2 (which is not the expected a1 a2 b1 b2, and different that a1 a2 b2 b1 obtained with runBlocking )

But that’s what you will get when calling a ‘real’ blocking method from some library. On a single threaded dispatcher you get a1 b1 a2 b2. On IO/Default you get a1 a2 b1 b2. The two

launch

start two concurrent coroutines. Because they don’t suspend though, they are not interleaved on a single threaded dispatcher.