Is there some way to hook into each suspend/yield point so a check can be performed to potentially cancel the current Job? My use case is implementing an Android ContentProvider’s blocking query() method, which takes a CancellationSignal as one (amongst others) argument. At the moment, I have to pass the CancellationSignal down through the code and perform checks at appropriate points, but it would be better if the check could be done via some kind of onSuspend callback.

you could implement a custom

ContinuationInterceptor

that wraps your dispatcher.

Can you explain a little more about that listener please?

Yep. That's the only way cancellation will immediately take effect if you get cancelled while suspended.

Wouldn’t

ContinuationInterceptor

also work?

The interceptor only gets invoked when a continuation object is created for suspension. If cancellation signal fires during suspension, the coroutine won't get cancelled until your interceptor sees it (on resumption). The whole point of cancellation is to stop long-running tasks before they finish, and the interceptor approach doesn't do that. I only suggested it because I didn't realize there was a callback API - it was a terrible suggestion lol.

I thought when a Job is cancelled the actual cancellation doesn’t kick in until a suspension point (or yield) is encountered. And that this is why we should call yield() in some loops etc. And that these points are the same points where the continuation object comes into play. Which part am I getting wrong here?

That’s not strictly true. Cancelling a Job does a few things: 1) Atomically sets a flag that the job is cancelled. After that point, anyone with access to that Job can see that it’s cancelled by calling

isActive/isCancelled

or calling

ensureActive()

, regardless of suspension – e.g. tight loops might call

ensureActive()

to cooperatively participate in cancellation. 2) Synchronously executes any cancellation logic registered via

invokeOnCancellation

(on Jobs or on `CancellableContinuation`s) – this logic and not guaranteed to be on any particular thread. 3) Immediately cancel all child jobs recursively, as part of structured concurrency. So there might be coroutines that don’t suspend at all, but still participate in cancellation. Cancellation and suspension are related, but cancellation involves a lot more than just resuming suspended coroutines, so cancellation should be propagated as quickly as possible.

Excellent, thank you @Zach Klippenstein (he/him) [MOD] That helps me a lot 🙏