When a component is destroyed, its CoroutineScope ...

# coroutines

[Zoltan Demant]

When a component is destroyed, its CoroutineScope is cancelled. Id like to do one last thing at that point, do I do GlobalScope.launch {} or `scope.launch(context = NonCancellable) {}`; or are they basically the same thing? My operation is just a few millis long.

[Stylianos Gakis]

Is that operation suspending? If it is not, can you try getting the Job object out of it and attaching a invokeOnCompletion on it?
Smth like

val myScope: CoroutineScope
myScope.coroutineContext[Job]?.invokeOnCompletion {
  delay()
}

[Zoltan Demant]

Thanks @Stylianos Gakis but unfortunately it's a suspend call!

[Nick Allen]

Do you need to wait for the other work to finish before the last thing is done? Does this last thing use any resources owned exclusively by the component?

When talking about CoroutineScope, we are talking about lifetimes of work and/or resources and the relationship between those lifetimes. So the answer depends on how your lifetimes are relate to each other.

Reserve GlobalScope for singleton's and resources that last the entire process. If your component has work with one lifetime and some other work with another, then feel free to use multiple `CoroutineScope`s (though it can also be a warning that you should split up your class).

I would never use scope.launch(context = NonCancellable) {}, calling launch with a context that contains a Job is confusing. I mean, if you aren't using the scope's job, why use it at all? If scope is cancelled, would this even run or no?

I probably wouldn't use GlobalScope.launch {} directly since if I'm using global resources (the only time I'd use GlobalScope) then I'd probably wrap those resources into a singleton and so I'd be calling a non-suspend method that calls GlobalScope.launch internally so invokeOnCompletion would work. But don't use GlobalScope to clean up resources owned by the component, you lose the ability to wait on scope to know when those resources are actually freed.

If I had work lifetime and a work+cleanup lifetime. I'd might go with something like:

val componentScope = CoroutineScope() //or however you define it
//Cancelling componentScope will also cancel workScope due to child/parent Jobs
//Waiting for componentScope, waits for work + cleanup to all finish
val workScope = CoroutineScope(SupervisorJob(componentScope.coroutineContext.job))
init {
    //UNDISPATCHED ensures it starts before cancellation could possibly happen
    componentScope.launch(start = CoroutineStart.UNDISPATCHED) {
        withContext(NonCancellable) { // clearer than passing it into launch
            workScope.join() //wait for all work to finish
            cleanUpSuspending()
        }
    }
}

[Zoltan Demant]

Thank you @Nick Allen! Thats a solution I probably wouldnt have thought of, but now that you mention it (and Ive dug into it a bit to understand how/why it work), it just makes sense and works perfectly for my use-case.

[Albert Chang]

Why don't you just do it in a finally block?
If you only want to do it when the coroutine is cancelled, then:

try {
    ...
} catch (e: CancellationException) {
    cleanUp()
    throw e
}

[Zoltan Demant]

@Albert Chang I guess that works too? I do like that its simpler and easier to reason about. Is that guaranteed to always run? Im just thinking about how a long running cleanUp (which isnt the case here, just trying to wrap my head around it) would keep a cancelled scope running, potentially forever?

[Zoltan Demant]

@Albert Chang Actually, it doesnt work.. CleanUp does get called, but isnt able to finish its work in time.

[Zoltan Demant]

If I wrap cleanUp in withContext(NonCancellable) it works, which makes sense

[Nick Allen]

If you don’t join on the other work, then the other work may still be running when you run your finally(if that's ok, then go ahead and skip the second scope), and if you don't use NonCancellable, then your suspending cleanup will throw a cancellation exception and not finish.

It’s not advisable to cleanup with suspending code but if you must, then always use a NonCancellable block.