Hey guys! I’m wondering if there’s a problem in the comment of `join` function:

# coroutines

[benny.huo]

Hey guys! I’m wondering if there’s a problem in the comment of join function:

[louiscad]

I think it's not so up to date. Calling join() doesn't throw if the job is cancelled but didn't crash (i.e. threw a CancellationException)

[benny.huo]

But I got a CancellationException when throws an Exception in the coroutine:

suspend fun main() {
    log(1)
    val job = GlobalScope.launch(Dispatchers.Unconfined) {
        log(2)
        val job2 = launch(Dispatchers.Default) {
            log(3)
            val x = 1 / 0
            log(4)
        }
        // if falls in the fast-path, a CancellationException will be thrown.
        job2.join() 
        log(5)
    }
    log(6)
    job.join()
    log(7)
}

[louiscad]

Do not use GlobalScope for this kind of stuff.

[louiscad]

Use coroutineScope { … }

[benny.huo]

Is there any problem with GlobeScope ? I changed to coroutineScope{...} and it seems to work normally.

[louiscad]

Yes, it's global

[benny.huo]

I cannot figure out the difference. When should we use GlobalScope?

[streetsofboston]

coroutineScope inherits its scope (the receiver of the lambda) from the calling/outer scope.

Using GlobalScope here will cause you to switch scope from the calling one to the GlobalScope. Cancelation and error-handling may get wonky...

Use GlobalScope if a coroutine runs as part of an object with a global lifecycle, eg a singleton global object.

[benny.huo]

Thanks a lot.

[Vsevolod Tolstopyatov [JB]]

This is outdated documentation, I will fix it, thanks

[benny.huo]

After I change to coroutineScope, CancallationException still happens when the child job’s join() is called. Just like GlobalScope does.

[benny.huo]

This is the result of the slow path joinSuspend.

[benny.huo]

This is the result of the fast path.

[benny.huo]

So the question is should we get a CancellationException when join on the crashing or crashed child job? I seems we will get the cancellation when join on a crashed child job while not on a crashing child job.

[benny.huo]

Finally, I figure out that when child job crashed, parent job will be canceled according to the propagation of exception thus making the join() call on child job canceled. While join on the running child job, when exception throws, the suspended join returns with a Unit and the parent job will be canceled later on. That makes sense although confusing.

[louiscad]

CancellationException is not considered as a crash, but other throwables are.