Dispatcher#unsafeRunTimed should also cancel() if Await.result is interrupted

[armanbilge]

i.e. if it throws an InterruptedException.

cats-effect/std/jvm/src/main/scala/cats/effect/std/DispatcherPlatform.scala

Lines 58 to 66 in 97b0174

	def unsafeRunTimed[A](fa: F[A], timeout: Duration): A = {
	val (fut, cancel) = unsafeToFutureCancelable(fa)
	try Await.result(fut, timeout)
	catch {
	case t: TimeoutException =>
	cancel()
	throw t
	}
	}

[djspiewak]

This is a good idea. We should probably also do it in IO. unsafeRunTimed is a bit bizarre because it's the only flavor of cancelation which doesn't backpressure and instead just yolo-disconnects from the computation. We need to keep that semantic (because it is designed to do precisely that), but this doesn't mean we shouldn't at least try to queue up the cancelation.

[armanbilge]

We should probably also do it in IO

I thought so, but it would be changing the explicitly documented API.

cats-effect/core/jvm/src/main/scala/cats/effect/IOPlatform.scala

Lines 47 to 48 in 328f61d

	* aborts and `None` is returned. Note that this does not run finalizers, which makes it quite
	* different (and less safe) than other mechanisms for limiting evaluation time.

For the record, I can't think why we wouldn't want to improve it 😅

[djspiewak]

Yeah I'm in favor of improving both.

[kotoji]

@armanbilge @djspiewak
I'm a beginner, and I think it might take me some time, but I'd like to give it a try.
If it's okay with you, could you please assign the issue to me?

[djspiewak]

It's all yours! Do you feel like you have a good idea on how to start? Feel free to ask questions here or in Discord (in the cats-effect-dev channel) and we'll be happy to help.

[kotoji]

@djspiewak
Thank you very much. I'm planning to start by doing some research to understand the content of the issue better. I might ask some basic questions, but I appreciate your support.

[kotoji]

@djspiewak
I would like to confirm my understanding of the approach for this issue.

The main content of this issue, as I understand it, is that we want to perform a cancel() operation when an InterruptedException is issued in the following places:

1. DispatcherPlatform#unsafeRunTimed
2. IOPlatform#unsafeRunTimed

Next, I will express my thoughts on how we should address this in both (1) and (2).

For (1), my thought is that we should handle an InterruptedException in the same way we do for a TimeoutException, by performing a cancel().

For (2), based on my interpretation of the following comment, #3967 (comment)

I thought the approach might be something like this:

• In the case of a timeout => yolo-disconnected (current implementation)
• In the case of being interrupted => cancel()

I'm not sure how to proceed with this, but I would like to confirm if my understanding is correct.

Or perhaps, even in the case of a timeout, is it acceptable to perform a cancel() instead of just being yolo-disconnected? In this case, I believe using unsafeToFutureCancelable() like in DispatcherPlatform#unsafeRunTimed seems to be a viable approach.