Matthew Massicotte - The Bleeding Edge of Swift Concurrency

Summary

The speaker shares their experiences with Swift concurrency, highlighting the complexities and challenges they faced when using it incorrectly. They emphasize the importance of understanding concurrency as a 'deeply hard' problem and discuss various issues such as task retention cycles, actor reentrancy, and the difficulties of maintaining order in asynchronous code. The presentation aims to raise awareness about potential pitfalls, promote best practices, and encourage developers to use the latest APIs and tools to avoid common concurrency-related mistakes.

Takeaways

• 🧠 The presentation is about the complexities and challenges of using Swift concurrency, focusing on the speaker's personal experiences with its misuse.
• 📈 The speaker emphasizes the importance of understanding Swift concurrency as it is neither simple nor easy, despite its potential to simplify certain tasks.
• 🔁 The concept of 'simple versus easy' is introduced to illustrate that some things may be easy to use but have deep underlying complexities.
• 🔒 The talk discusses issues with Swift's actor model, such as difficulties with capturing 'self' weakly and the challenges of asynchronous sequences.
• 💡 It highlights problems with main actor isolation in Swift UI and how property wrappers can implicitly change the global actor.
• 🚧 The speaker shares their experiences with concurrency issues, such as the actor re-entrancy problem when caching values in an actor.
• 🛠️ Solutions to concurrency problems are explored, like using 'async semaphore' for managing critical sections in a thread-safe manner.
• ⚠️ The script points out the importance of making dependencies explicit in asynchronous code to avoid race conditions.
• 🔧 The use of 'async unsafe' APIs is introduced to bypass the 'sendable' requirement for closures, which helps with updating UI and protecting mutable state.
• 🛑 The speaker discusses the implications of a strict Swift concurrency build setting that led to numerous warnings and the need to address these issues proactively.
• 🔄 The presentation concludes with a cautionary tale about the dangers of building APIs incompatible with Swift concurrency and the need for developers to be aware and plan for upcoming changes in Swift 6.

Q & A

What is the main topic of the presentation?

The main topic of the presentation is Swift concurrency and the experiences of using it, particularly focusing on the challenges and issues encountered when using it incorrectly.

Why does the presenter want to leave the audience with a bit of fear?

The presenter wants to leave the audience with a bit of fear, or rather a healthy respect, for Swift concurrency to highlight the potential issues and complexities that can arise from its misuse.

What is the difference between 'simple' and 'easy' as discussed in the presentation?

In the presentation, 'simple' refers to things that are easy to understand once the concepts behind them are grasped, but may require significant effort to initially understand. 'Easy' refers to things that can be used with little effort to learn but may be fundamentally complicated underneath.

What is the presenter's view on Swift concurrency in terms of simplicity and ease of use?

The presenter believes that Swift concurrency is neither simple nor easy. It is a complex system that, despite its potential to make things easier, can be challenging to use correctly and can lead to many problems if not handled properly.

What is the 'international unit of fear' mentioned by the presenter?

The 'international unit of fear' is a humorous term used by the presenter to quantify the level of concern or caution one should have when dealing with Swift concurrency issues, with 'scared beakers' being the unit of measurement.

Can you explain the issue with capturing 'self' in asynchronous tasks in Swift?

The issue with capturing 'self' in asynchronous tasks in Swift is related to the potential for creating retained cycles that can lead to memory leaks. The Swift team decided not to enforce capturing 'self' weakly by default to avoid breaking existing code and to allow for flexibility.

What is the problem with using async sequences and how can it lead to memory leaks?

Async sequences can lead to memory leaks because if they are effectively infinitely long, they may never finish executing, leading to the retention of 'self' indefinitely. This can happen if the async sequence is started and then suspended without properly completing.

Why does the presenter mention 'main actor' functions and their relation to tasks?

The presenter mentions 'main actor' functions because they have a specific context that tasks inherit when started. This can lead to unexpected behavior if a task is intended to run on a different actor but instead runs on the main actor due to inheritance.

What is the issue with property wrappers and how do they relate to 'main actor' isolation?

Property wrappers can implicitly change the global actor isolation of their enclosing type, which can lead to confusion and errors. This behavior has been identified as problematic, and there are proposals to change this behavior in Swift Evolution.

What is the 'actor re-entrancy problem' and how does it relate to caching in Swift concurrency?

The 'actor re-entrancy problem' occurs when an actor starts an asynchronous task that suspends, allowing other threads to enter the actor and perform the same operation, potentially leading to duplicated work or other issues. This can happen when caching values in an actor if not handled correctly.

How does the presenter suggest handling the ordering issues in asynchronous code?

The presenter suggests making dependencies explicit to handle ordering issues in asynchronous code. This can involve capturing a reference in one task and awaiting it in another to ensure that the operations occur in the correct order.

What is the significance of the 'async semaphore' in the context of Swift concurrency?

The 'async semaphore' is a package that provides a semaphore that is safe to use with Swift's concurrency model. It allows for synchronization similar to traditional locks but in a way that is compatible with Swift's async/await syntax and concurrency features.

What are the implications of the 'sendable' requirement in Swift's asynchronous functions?

The 'sendable' requirement implies that any value passed to an asynchronous function must be safely sendable across different threads or execution contexts. This can be problematic for types that are not sendable, such as UI-related objects, and may require workarounds or changes to the API design.

What is the presenter's stance on the Swift concurrency build setting?

The presenter advises turning up the Swift concurrency build setting to the maximum to get a full picture of potential issues in the code. They argue that it is better to be aware of these issues early on and plan for how to address them rather than building APIs that are fundamentally incompatible with Swift concurrency.

What does the presenter suggest for dealing with Swift 6's stricter concurrency requirements?

The presenter suggests that developers should start turning on the concurrency warnings in their builds to find and address problems in their code before Swift 6, where these warnings will become errors. This will help avoid building APIs that won't work with the new concurrency model.