@deviant

EmptyCoroutineContext

and

Unconfined

are virtually the same with the exception that

Unconfined

is designed to work with debugging facilities of

kotlinx.coroutines

(in debug mode you’ll get the id of the executing coroutine added to the thread name — wastes a lot of CPU, but simplifies debugging)

thanks, Roman. do i understand correct that i can use

launch(EmptyCoroutineContext)

in the ui thread with same result i call

launch(UI)

?

If you

launch(EmptyCoroutineContext)

or

launch(Unconfined)

in UI thread, then after the first async operation like

delay

you’ll resume in some other thread and will not be in UI thread anymore. However, with

launch(UI)

you always resume in UI thread, guaranteed. It is explained with examples in this section of the guide: https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#unconfined-vs-confined-dispatcher

is it valid only for

delay

coroutine? because i can't reproduce 'thread switching' with

async(CommonPool){...}.await()

launch(Unconfined){
        logThread("coroutine start")
        async(CommonPool){
            logThread("common pool")
        }.await()
        logThread("coroutine end")

    }

It is true with any suspending function. In your example, I think, the

async(CommonPool)

coroutine just finishes too fast, so that

await

does not suspend and stays in the same thread. Just spin there for while to see how

Unconfined

coroutine can jump threads.

wow. with

Thread.sleep()

inside of

async

now it jumps to another thread. thanks for clarification

Btw, the pair of

async(ctx) { ... }.await()

is the same as

run(ctx) { ... }

. I’d recommend to always use the later, since it makes your intent to switch to another context more explicit and I don’t have to look at the last line with

await

to see what was your intent of using

async

.