Jared Sinclair@mattiem Would you be available to chat sometime (for 20~30mins) about what I think is a major concurrency bug in Swift? I think child task cancellation is broken. Perhaps sometime this week or next? I need a second pair of eyes before I'm sure. It'd be easier over a screenshare. My email is desk at jaredsinclair dot com If not... no worries at all.
@mattiem Thanks for the chat. I've opened a PR (my first) at swiftlang/swift to improve the documentation https://github.com/swiftlang/swift/pull/85861 - The source code documentation is misleading on this topic, whereas the programming book is not.
Matt Massicotte@jaredsinclair Of course! This is funny too because I found another, different documentation bug just this morning.
I do have a question for you though. Is your usage of cancellation purely to avoid wasting work, or are there cases where it is semantically important?
@mattiem Runs the gamut. There are literally 700+ places in our codebase where an unstructured Task is initialized. Some of them are just drive-by tasks where cancellation doesn't matter, but others are `let task = Task {...}` dances that are part of complex user-driven work flows (two-factor authentication, f.ex.) where cancellation can come from below or from above and needs to propagate throughout multiple sub-workflows.
@jaredsinclair Yes this makes sense. But I’d love to hear details about situations where it is logically important that a cancellation a) happens and/or b) in a specific ordering relative to other work.
@mattiem A reviewer noted that calling `cancel()` on SomeScreenSomewhere did not propagate downward and cause the checked continuation to throw the cancellation. Result: "Cancel" button appeared to be inert.
BTW, this pseudocode would be closer to a reality once your typed-throws on Tasks proposal gets approved. There's a lot of unfortunate do/catch and ?? in the real implementation.
