natario1
03/29/2023, 9:24 AMouterScope END
log in this example? https://pl.kotl.in/BMb6dLHG- It creates an outerScope, jumps on innerScope using withContext
, then cancels outerScope while it’s running.
Docs say:
Note that the result ofSo I would expectinvocation is dispatched into the original context in a cancellable way with a prompt cancellation guarantee, which means that if the original coroutineContext in whichwithContext
was invoked is cancelled by the time its dispatcher starts to execute the code, it discards the result ofwithContext
and throws CancellationException.withContext
withContext
to, basically, throw before returning.Sam
03/29/2023, 9:29 AMwithContext
, you’re basically making it ignore cancellation of the outer scope. The behaviour is the same as if you wrote withContext(NonCancellable)
.natario1
03/29/2023, 9:31 AMinnerScope END
line). But docs say it should throw before returning, after switching back to the outer context.Sam
03/29/2023, 9:36 AMThe cancellation behaviour described above is enabled if and only if the dispatcher is being changed. For example, when using withContext(NonCancellable) { ... } there is no change in dispatcher and this call will not be cancelled neither on entry to the block inside withContext nor on exit from it.
outerScope END
message.natario1
03/29/2023, 9:39 AMSam
03/29/2023, 9:49 AMCLOVIS
03/29/2023, 9:51 AMnatario1
03/29/2023, 9:54 AMCLOVIS
03/29/2023, 9:55 AMnatario1
03/29/2023, 9:57 AMwithContext
, so the contents of withContext can already react to cancellation. But if job is different it would be nice to have one for consistency