fun main(args: Array<String>) = runBlocking {
            val job = launch(CommonPool) {
                var nextPrintTime = System.currentTimeMillis()
                var i = 0
                while (i < 10) { // computation loop
                    val currentTime = System.currentTimeMillis()
                    if (currentTime >= nextPrintTime) {
                        println("I'm sleeping ${i++} ...")
                        nextPrintTime += 500L
                    }
                }
            }
            delay(1300L) // delay a bit
            println("main: I'm tired of waiting!")
            job.cancel() // cancels the job
            delay(1300L) // delay a bit to see if it was cancelled....
            println("main: Now I can quit.")
            }

Why is the job not cancelled after calling it explicitly?

Because it never suspends. It just keeps looping, so there is no way to cancel it.

fun main(args: Array<String>) = runBlocking<Unit> {
    val job = launch(CommonPool) {
        repeat(1000) { i ->
            println("I'm sleeping $i ...")
            delay(500L)
        }
    }
    delay(1300L) // delay a bit
    println("main: I'm tired of waiting!")
    job.cancel() // cancels the job
    delay(1300L) // delay a bit to ensure it was cancelled indeed
    println("main: Now I can quit.")
}

Well this suspends

Yes, and it should be canceled here.

It gets cancelled after

job.cancel()

Because the first time the coroutine does not suspend. It just runs and runs and there is no way for the coroutine machinery to make it stop. If you suspend every once in a while, you will just not get re-scheduled (un-suspended) when you're canceled.

Thanks!

cancellation is cooperative, means you should check if job is cancelled inside your

repeat

lambda https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#cancellation-is-cooperative

@elizarov maybe we need a primitive that would suspend, check for cancelation, then immediately resume. Something like

delay(0)

, but optimized for that scenario. Then it could be inserted into long-running jobs like above

I think it will be much better if the implementor designs his code such that it is cooperative. That way, there shouldn’t be a need for any trick.

don't we have

yield()

for this?

you can also have

launch(CommonPool)

inside the

repeat

. In this case I suppose after calling

job.cancel()

coroutine won’t proceed after latest

delay(500L)

. The drawback is frequent context switching.

Ah. Yes.

yield

. For a moment, I thought that was only available to

generateSequence