[Accepted] SE-0504: Task Cancellation Shields

Evolution Announcements
,
5

Maybe I misunderstood the exchange, but towards the end of your post you mentioned having Task.isCancelled == task.isCancelled as "a way to query if we're under a shield":

(It would also incidentally make Task.isCancelled == task.isCancelled a way to query if we're under a shield for debugging purposes, without vending a dedicated API that we have to then warn people not to use in production—see previous section.)

But this is distinct from the behavior of hasActiveTaskCancellationShield, as the latter is true even when the shield is not changing the value of Task.isCancelled.

That was pointed out in the replies, where this example came up:

Task {
  withTaskCancellationShield {
    withUnsafeCurrentTask {
      print($0!.hasActiveTaskCancellationShield)
    }
  }
}

And it was then confirmed that the shield is "active" (hasActiveTaskCancellationShield returns true) regardless of whether the current task is cancelled or not.

This exchange is what led me to believe —perhaps mistakingly— that there had been different interpretations of the meaning of hasActiveTaskCancellationShield in the thread. If that was not the case, well, that'd explain a lot!

But then I'm not quite getting the point you're making here:

If the behavior of hasActiveTaskCancellationShield is that it's unconditionally true when queried from within the scope of a withTaskCancellationShield { ... }, how can you "have" the shield but not have it "active"?

Unless you're saying that even outside of a withTaskCancellationShield { ... } scope you somehow also "have" a shield, because a bit exists in the internal representation of a task to set one? But the API is literally called with[...]Shield { ... }, how could anyone conceivably interpret that you "have" a shield outside that scope too?

1 Like