Practical solutions to problems with Swift Concurrency
Swift Concurrency can be really hard to use. I thought it could be handy to document and share solutions and hazards you might face along the way. I am absolutely not saying this is comprehensive, or that the solutions presented are great. I'm learning too. Contributions are very welcome, especially for problems!
Warning
I have not updated the code in this repo for Swift 6.0. And on top of changes to the language, which were substantial, my general understandings/opinions have changed as well. I'm still absolutely interested in your feedback/issue reports! But, please keep all this in mind when looking through the repo.
- Creating an Async Context
- Using Protocols
- Isolation
- Structured Concurrency
- SwiftUI
- Using Libraries not Designed for Concurrency
- Interoperability
Quick definitions for the hazards referenced throughout the recipes:
- Timing: More than one option is available, but can affect when events actually occur.
- Ordering: Unstructured tasks means ordering is up to the caller. Think carefully about dependencies, multiple invocations, and cancellation.
- Lack of Caller Control: definitions always control actor context. This is different from other threading models, and you cannot alter definitions you do not control.
- Sendability: types that cross isolation domains must be sendable. This isn't always easy, and for types you do not control, not possible.
- Blocking: Swift concurrency uses a fixed-size thread pool. Tying up background threads can lead to lag and even deadlock.
- Availability: Concurrency is evolving rapidly, and some APIs require the latest SDK.
- Async virality: Making a function async affects all its callsites. This can result in a large number of changes, each of which could, itself, affect subsequence callsites.
- Actor Reentrancy: More than one thread can enter an Actor's async methods. An actor's state can change across awaits.
I would love to hear from you! Issues or pull requests work great. You can also find me on the web.
I prefer collaboration, and would love to find ways to work together if you have a similar project.
I prefer indentation with tabs for improved accessibility. But, I'd rather you use the system you want and make a PR than hesitate because of whitespace.
By participating in this project you agree to abide by the Contributor Code of Conduct.