mattmassicotte/concurrencyrecipes

Table of Contents

• Creating an Async Context
• Using Protocols
• Isolation
• Structured Concurrency
• SwiftUI
• Using Libraries not Designed for Concurrency
• Interoperability

Hazards

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.

Contributing and Collaboration

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.

Package Metadata

Repository: mattmassicotte/concurrencyrecipes

Default branch: main

README: README.md