I have a long running CPU-heavy task. I want it to be cancellable, so I need to pass in something th...

# coroutines

[Sam]

I have a long running CPU-heavy task. I want it to be cancellable, so I need to pass in something that will let it know when its Job becomes cancelled.
• Adding the suspend modifier would give access to the currentCoroutineContext(), but it doesn't seem appropriate since the function doesn't actually suspend.
• Adding a CoroutineScope receiver would also give access to the coroutine context, but that also doesn't seem appropriate since the function doesn't launch any coroutines.
• I could use thread interrupts and call the function from a runInterruptible block, but that seems like a lot of hard work, and it's JVM only
Which would you pick? Any established conventions for this? Maybe there's another option I haven't considered?

[Sam]

In an ideal world, the function wouldn't need to know about coroutines

[ephemient]

suspend and call checkActive() periodically?

[ephemient]

regular code just isn't interruptible

[Sam]

Right, I'd need to modify the code to include the check somehow. I'm just trying to decide on the best way to do the check. Whether that's by checking the Job, using ensureActive() like you said, checking the thread interrupt status manually, or setting up some other variable to check.

[Sam]

At the moment the function doesn't know anything about coroutines or suspension points, and it'd be nice to keep it that way so it can be called from other places too

[ephemient]

thread interruption is JVM only, and also only happens at specific points

[Sam]

Yeah, it'd be my first choice if it wasn't JVM specific. I can check Thread.interrupted() without introducing any coroutine dependencies, but only on JVM 😞

[ephemient]

coroutine cancellation and thread interruption are cooperative, there isn't a (safe) way to stop uncooperative code

[ephemient]

so either way you have to choose what to interop with

[Sam]

Maybe I'll just pass in a isActive: () -> Boolean to my function to break the explicit dependency on coroutines

[ephemient]

okhttp has a https://square.github.io/okio/3.x/okio/okio/okio/-timeout/index.html abstraction, although it only works on JVM the idea could be applied elsewhere

[Sam]

I might actually be changing my mind about the dependency on coroutines; I think my task should probably be a good neighbour and use yield(), which will do the trick for cancellability too. Maybe that's why there isn't another common pattern for this.

[kevin.cianfarini]

Is this CPU intensive task running on a separate thread? Is it a loop? If so, it might make sense to have two functions.

1. The inner loop code is a separate function. This does not know about coroutines.
2. The loop itself is suspend and does a while(isActive) to ensure it cancels cooperatively.

[kevin.cianfarini]

Though, I think your solution of isActive: () -> Boolean is probably better.

[louiscad]

currentCoroutineContext().isActive is probably what you need

[gildor]

I think there is nothing bad from making it suspend, even if it not actually suspend
Coroutine cancellation sematics is clear and easy to use from any suspend function, than custom isActive, which anyway would be implemented like { currentCoroutineContext().isActive }

Also if CPU heavy, explicitly wrapping content to appropriate dispatcher (like Default) makes it safe to call from any suspend function