-
Notifications
You must be signed in to change notification settings - Fork 1.9k
withContext doesn't check for cancellation before running the block #785
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I've partially addressed this issue in #791 I don't think it's really necessary to check it on the beginning of the block because it will be thrown on the first suspension point anyway, and if you are using some in-place builder you will suspend soon. While a desire to insert cancellation checks everywhere is understandable, we should remember that they are not free. |
Nothing is free, but I'm wondering about the cost of checking the boolean property About checking cancellation only on exit, I'm now wondering if checking cancellation before enter is useful in practical use cases, as you usually launch the coroutine already on the first dispatcher you want to use, and if you switch afterwards, it was likely because of previous suspension points (that may check for cancellation before you reach withContext). Do you think there are practical use cases for this? If there is none, #791 probably resolves this issue on its own. |
Can I ask a small confirmation as my tests did gave a different result about withContext checking for cancellation at the end. @qwwdfsad does your PR changes also withContext and it is currently not checking? I've made a lot of tests and finally left the code secure with a manual check for isActive after withContext
But from all my tests when cancelling the coroutine it's stopped before reaching the if. |
The current implementation of
withContext
doesn't seem to check for cancellation (likeyield()
would for example) before running the passed block.I didn't double check, but if I remember correctly, it doesn't check for cancellation after running the block either.
I think
withContext
checked for cancellation before and after running the block in the past (at some point before 1.0). I don't recall seeing any release notes about this though, so maybe I made false assumptions.Anyway, I think it would be great to throw a
CancellationException
if the coroutine has been cancelled before running the block, and after it has been run before resuming the parent coroutine.Cancellation is an important part of the efficiency coroutines brings to our programs. The earlier you stop doing something no longer needed, the earlier you start saving resources.
The text was updated successfully, but these errors were encountered: