@snoyberg you said here #41 (comment) that you wouldn't mind the waitCatch in cancel being interruptible, but what we ended up with (I only just realised) is that it is uninterruptible in the context of withAsync, and this ticket argues for it always to be uninterruptible.
@simonmar me and @snoyberg had various discussions after that comment and he agreed that uninterruptible cancel by default is the way to go. I think he'll also be available later today so he can reply himself :)
I was mistaken in that comment, as @bitonic convinced me. We definitely need to deliver the exception to the child thread, so making the cancel uninterruptible makes sense. There's still an argument for making the waitCatch interruptible.
@snoyberg it was the waitCatch I was talking about (and what your earlier comment was about). Since uninterruptibleCancel now includes the waitCatch, the waitCatch in withAsync is now uninterruptible. Is that what we want?
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.