what’s the recommend pattern to launch a non-cance...

# coroutines

[zak.taccardi]

what’s the recommend pattern to launch a non-cancellable coroutine from within a cancellable CoroutineScope?

[zak.taccardi]

using GlobalScope works, but is it recommend?

[Allan Wang]

Maybe with a NonCancellable context?

[Allan Wang]

It also depends on your application. If the data returned is used by anything with a lifecycle, then it usually doesn’t need to be noncancellable. If it must live on regardless of the caller, then GlobalScope seems reasonable

[zak.taccardi]

what would the difference be between using NonCancellable and GlobalScope?

[simon.vergauwen]

AFAIK you cannot with what's available in kotlinx.coroutines. Reason being that you're already within a cancelable context, so this would require writing a runner that can take into account a context switch?

[simon.vergauwen]

If you figure this out please let me know :)

[Allan Wang]

Someone else may clarify, but I believe usage wise they are similar. NonCancellable still has a job, thought it is always active, whereas globalscope doesn’t have a job in its context.

For NonCancellable, you can wrap part of your execution with it, and leave the remaining executions cancellable. In that case, your full job will cancel prematurely if it is cancelled, just not within the noncancellable scope. You can probably still do this with GlobalScope though.

[Allan Wang]

I think the biggest difference is that one replaces the scope whereas the other replaces the context

[zak.taccardi]

basically I have an API like

// invoked within a cancellable scope
processStarter.start { result ->
  // even if the scope is cancelled, this launch coroutine MUST be executed
  launch {
     // suspending function, which is why the `launch` above is needed
     mustDeliverResult(result)
  }
}

the start { .. } lambda is not tied to any coroutine and is just a callback that once returned, must deliver its result

[zak.taccardi]

I believe there are two solutions.

launch(NonCancellable + Dispatchers.Unconfined) {
  mustDeliverResult(result)
}

and

GlobalScope.launch(Dispatchers.Unconfined) {
  mustDeliverResult(result)
}

I’m also using Dispatchers.Unconfined too because I want that result delivered ASAP, and not posted to an executor or queued up.

I’m not sure why I might choose one solution over the other

[Allan Wang]

I think in your case either works. It comes down to what your function does.

If your function needs to launch a new task, it’s easier to make it a normal function and use GlobalScope.launch.

If your function is a suspended function and you want to make it noncancellable, it’s easier to use withContext(NonCancellable) { ... }

You have the liberty of using either since you are in a scope.

[simon.vergauwen]

What I am not sure I understand is that if the parent scope gets cancelled, how does that prevent the child scope of not being cancelled. Which is what happens if you call withContext within another scope, right?

[zak.taccardi]

The lambda in start { .. } is a (ProcessResult) -> Unit, so it's not being called from any suspending context

[simon.vergauwen]

Oh okay, I missed that part. Thanks!