withThrowingTaskGroup – Augmented Code

Task groups in Swift are used for running n-number of child tasks and letting it handle things like cancellation or different priorities. Task groups are created with either withThrowingTaskGroup(of:returning:body:) or withTaskGroup(of:returning:body:). The latter is for cases when errors are not thrown. In this blog post, we will observe two cases of generating Data objects using a task group. In the first case, we want to stop the group as soon as an error has occurred and discard all the remaining work. The other case looks at ignoring any errors in child tasks and collect just collecting Data objects for tasks which were successful.

The example we are going to use simulates creating image data for multiple identifiers and then returning an array of Data objects. The actual image creating and processing is simulated with Task’s sleep function. Since task groups coordinate cancellation to all the child tasks, then the processor implementation also calls Task.checkCancellation() to react to cancellation and stopping as soon as possible for avoiding unnecessary work.

	struct ImageProcessor {
	static func process(identifier: Int) async throws -> Data {
	// Read image data
	try await Task.sleep(nanoseconds: UInt64(identifier) * UInt64(1e8))
	try Task.checkCancellation()
	// Simulate processing the data and transforming it
	try await Task.sleep(nanoseconds: UInt64(1e8))
	try Task.checkCancellation()

	if identifier != 2 {
	print("Success: \(identifier)")
	return Data()
	}
	else {
	print("Failing: \(identifier)")
	throw ProcessingError.invalidData
	}
	}

	enum ProcessingError: Error {
	case invalidData
	}
	}

view raw ImageProcessor.swift hosted with ❤ by GitHub

Now we have the processor created. Let’s see an example of calling this function from a task group. As soon as we detect an error in one of the child tasks, we would like to stop processing and return an error from the task group.

	let imageDatas = try await withThrowingTaskGroup(of: Data.self, returning: [Data].self) { group in
	imageIdentifiers.forEach { imageIdentifier in
	group.addTask {
	return try await ImageProcessor.process(identifier: imageIdentifier)
	}
	}
	var results = [Data]()
	for try await imageData in group {
	results.append(imageData)
	}
	return results
	}

view raw Case1.swift hosted with ❤ by GitHub

We loop over the imageIdentifiers array and create a child task for each of these. When child tasks are created and running, we wait for child tasks to finish by looping over the group and waiting each of the child task. If the child task throws an error, then in the for loop we re-throw the error which makes the task group to cancel all the remaining child tasks and then return the error to the caller. Since we loop over each of the task and wait until it finishes, then the group will throw an error of the first added failing task. Also, just to remind that cancellation needs to be handled explicitly by the child task’s implementation by calling Task.checkCancellation().

Great, but what if we would like to ignore errors in child tasks and just collect Data objects of all the successful tasks. This could be implemented with withTaskGroup function by specifying the child task’s return type optional and handling the error within the child task’s closure. If error is thrown, return nil, and later when looping over child tasks, ignore nil values with AsyncSequence’s compactMap().

	let imageDatas = await withTaskGroup(of: Data?.self, returning: [Data].self) { group in
	imageIdentifiers.forEach { imageIdentifier in
	group.addTask {
	do {
	return try await ImageProcessor.process(identifier: imageIdentifier)
	} catch {
	return nil
	}
	}
	}
	var results = [Data]()
	for await imageData in group.compactMap({ $0 }) {
	results.append(imageData)
	}
	return results
	}

view raw Case2.swift hosted with ❤ by GitHub

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Support me on Patreon

Donate with Paypal

Running tasks in parallel with async-await in Swift

Async-await in Swift supports scheduling and running multiple tasks in parallel. One of the benefits is that we can schedule all the async operations at once without worrying about any thread explosions. Thread explosion could have happened with DispatchQueue APIs if our queue is concurrently performing, and we would add a lot of work items to it. The structured concurrency on the other hand makes sure this does not happen by only running a limit amount of tasks at the same time.

Let’s take an example where we have a list of filenames, and we would like to load images for these filenames. Loading is async and might also throw an error as well. Here is an example how to use the TaskGroup:

	@MainActor final class ViewModel: ObservableObject {
	let imageNames: [String]

	init(imageNames: [String]) {
	self.imageNames = imageNames
	}

	func load() {
	Task {
	let store = ImageStore()
	let images = try await withThrowingTaskGroup(of: UIImage.self, body: { group in
	imageNames.forEach { imageName in
	group.addTask {
	try await store.loadImage(named: imageName)
	}
	}
	return try await group.reduce(into: [UIImage](), { $0.append($1) })
	})
	self.images = images
	}
	}

	@Published var images = [UIImage]()
	}

	struct ImageStore {
	func loadImage(named name: String) async throws -> UIImage {
	return …
	}
	}

view raw ViewModel.swift hosted with ❤ by GitHub

In our view model, we have a load function which creates a task on the main actor. On the main actor because the view model has a @MainActor annotation. The Swift runtime makes sure that all the functions and properties in the view model always run on the main thread. This also means that the line let store runs on the main thread as well because the created task belongs to the main actor. If a task belongs to an actor, it will run on the actor’s executor. Moreover, all the code except the child task’s closure containing loadImage runs on the main thread. This is because our ImageStore does not use any actors. If ImageStore had @MainActor annotation, then everything would run on the main thread and using task group would not make any sense. If we remove the @MainActor from the view model, then we can see that let store starts running on a background thread along with all the other code in the load function. That is a case of unstructured concurrency. Therefore, it is important to think about if code has tied to any actors or not. Creating a task does not mean it will run on a background thread.

But going back to the TaskGroup. Task groups are created with withThrowingTaskGroup or when dealing with non-throwing tasks then withTaskGroup function. This function creates a task group where we can add tasks which run independently. For getting results back from the group, we can use AsyncSequence protocol functions. In this simple example, we just want to collect results and return them. Async sequence has reduce function which we can use exactly for that.

To summarize what we achieved in the code snippet above. We had a list of filenames which we transformed into a list of UIImages by running the transformation concurrently using a task group. In addition, we used MainActor for making sure UI updates always happen on the main thread.

If this was helpful, please let me know on Mastodon@toomasvahter or Twitter @toomasvahter. Feel free to subscribe to RSS feed. Thank you for reading.

Support me on Patreon

Donate with Paypal