Structured Concurrency difference between addTask and addTaskUnlessCancelled Swift - ios

Question

I am have confusion between Calling addTask() and addTaskUnlessCancelled. By definition addTask() on your group will unconditionally add a new task to the group
func testCancellation() async {
do {
try await withThrowingTaskGroup(of: Void.self) { group -> Void in
group.addTaskUnlessCancelled {
print("added")
try await Task.sleep(nanoseconds: 1_000_000_000)
throw ExampleError.badURL
}
group.addTaskUnlessCancelled {
print("added")
try await Task.sleep(nanoseconds: 2_000_000_000)
print("Task is cancelled: \(Task.isCancelled)")
}
group.addTaskUnlessCancelled {
print("added")
try await Task.sleep(nanoseconds: 5_000_000_000)
print("Task is cancelled: \(Task.isCancelled)")
}
group.cancelAll()
try await group.next()
}
} catch {
print("Error thrown: \(error.localizedDescription)")
}
}
If you want to avoid adding tasks to a cancelled group, we have to use the addTaskUnlessCancelled() method. But even with group.cancelAll(), it is adding all Task to group. Then what's the difference here and returning value which return true only if Task throws some error?

Answer 1

Short answer
The virtue of addTaskUnlessCancelled is that:
it will not even start the task if the group has been canceled; and
it allows you to add an early exit if the group has been canceled.
If you are interested, you can compare the source code for addTask with that of addTaskUnlessCancelled, right below it.
Long answer
I think the problem is best exemplified if we change the task group is processing requests over time (e.g. consuming an AsyncSequence).
Consider the following
func a() async {
await withTaskGroup(of: Void.self) { group in
for await i in tickSequence() {
group.addTask(operation: { await self.b() })
if i == 3 {
group.cancelAll()
}
}
}
}
func b() async {
let start = CACurrentMediaTime()
while CACurrentMediaTime() - start < 3 { }
}
func tickSequence() -> AsyncStream<Int> {
AsyncStream { continuation in
Task {
for i in 0 ..< 12 {
try await Task.sleep(nanoseconds: NSEC_PER_SEC / 2)
continuation.yield(i)
}
continuation.finish()
}
}
}
In this example, b is awaiting tick sequence events, calling c for each one. But we cancel the group after the fourth task is added. That results in the following:
So we can see the signpost ⓢ where the group was canceled after the fourth task was added, but it proceeded unaffected.
But that is because b is not responding to cancelation. So let's say you fix that:
func b() async {
let start = CACurrentMediaTime()
while CACurrentMediaTime() - start < 3 {
if Task.isCancelled { return }
}
}
You now see behavior like the following:
That is better, as b is now canceling, but a is still attempting to add tasks to the group even though it has been canceled. And you can see that b is repeatedly running (though at least it is now immediately terminating) and the task initiated by a is not finishing in a timely manner.
However, if you use group.addTaskUnlessCancelled it not only will not add new tasks to the group at all (i.e., it does not rely on the cancellation capabilities of the task), but it also lets you exit when the group is canceled.
func a() async {
await withTaskGroup(of: Void.self) { group in
for await i in tickSequence() {
guard group.addTaskUnlessCancelled(operation: { await self.b() })
else { break }
if i == 3 {
group.cancelAll()
}
}
}
}
That results in the desired behavior:
Obviously, this is a rather contrived example, explicitly constructed to illustrate the difference, but in many cases, the difference between addTask and addTaskUnlessCancelled is less stark. But hopefully the above illustrates the difference.
Bottom line, if you might be canceling groups in the middle of adding additional tasks to that group, addTaskUnlessCancelled is well advised. That having been said, if you do not cancel groups (e.g., canceling tasks is more common than canceling groups, IMHO), it is not entirely clear how often addTaskUnlessCancelled will really be needed.
Note, in the above, I removed all of the OSLog and signpost code to generate all of the above intervals and signposts in Xcode Instruments (as I did not want to distract from the question at hand). But, if you are interested, this was the actual code:
import os.log
private let log = OSLog(subsystem: "Test", category: .pointsOfInterest)
func a() async {
await withTaskGroup(of: Void.self) { group in
let id = log.begin(name: #function, "begin")
defer { log.end(name: #function, "end", id: id) }
for await i in tickSequence() {
guard group.addTaskUnlessCancelled(operation: { await self.b() }) else { break }
if i == 3 {
log.event(name: #function, "Cancel")
group.cancelAll()
}
}
}
}
func b() async {
let id = log.begin(name: #function, "begin")
defer { log.end(name: #function, "end", id: id) }
let start = CACurrentMediaTime()
while CACurrentMediaTime() - start < 3 {
if Task.isCancelled { return }
}
}
func tickSequence() -> AsyncStream<Int> {
AsyncStream { continuation in
Task {
for i in 0 ..< 12 {
try await Task.sleep(nanoseconds: NSEC_PER_SEC / 2)
continuation.yield(i)
}
continuation.finish()
}
}
}
With
extension OSLog {
func event(name: StaticString = "Points", _ string: String) {
os_signpost(.event, log: self, name: name, "%{public}#", string)
}
/// Manually begin an interval
func begin(name: StaticString = "Intervals", _ string: String) -> OSSignpostID {
let id = OSSignpostID(log: self)
os_signpost(.begin, log: self, name: name, signpostID: id, "%{public}#", string)
return id
}
/// Manually end an interval
func end(name: StaticString = "Intervals", _ string: String, id: OSSignpostID) {
os_signpost(.end, log: self, name: name, signpostID: id, "%{public}#", string)
}
func interval<T>(name: StaticString = "Intervals", _ string: String, block: () throws -> T) rethrows -> T {
let id = OSSignpostID(log: self)
os_signpost(.begin, log: self, name: name, signpostID: id, "%{public}#", string)
defer { os_signpost(.end, log: self, name: name, signpostID: id, "%{public}#", string) }
return try block()
}
}