Watch Out for Counterintuitive Implicit Actor-Isolation
I ran into some unexpected runtime crashes recently while testing an app on iOS 18 compiled under Swift 6 language mode, and the root causes ended up being the perils of using
@unchecked Sendablein combination with some counterintuitive compiler behavior with implicit actor isolation.[…]
What occurred to me instead was to find a way to use locking mechanisms to synchronize access to the
static varmutable property. What happened next led me down a path to some code that (A) compiled without warnings or errors but (B) crashed hard at runtime due to implicit actor isolation assertion failures.[…]
It turns out that the implicit Main Actor isolation is getting introduced by
MyApp[…] Therefore thatinit()method is isolated to the Main Actor. But ourLogging.sinkmember is not isolated to the Main Actor. It’s implicitlynonisolated, so why is the compiler inferring Main Actor isolation for the block we pass to it?
What’s happening here is the compiler is reasoning “this closure is not Sendable so it couldn’t possibly change isolation from where it was formed and therefore its body must be MainActor too” but your unchecked type allows this invariant to be violated. This kind of thing comes up a lot in many forms, and it’s hard to debug…
Mutex is a potential solution but requires iOS 18. He also shows how to protect the sink with a non-global actor.
Previously:
- Swift Vision: Improving the Approachability of Data-Race Safety
- Problematic Swift Concurrency Patterns
- Swift Concurrency and Objective-C
- Unwanted Swift Concurrency Checking
- Swift 6
- Swift Proposal: Synchronous Mutual Exclusion Lock
- Noncopyable Generics Walkthrough
- Swift Proposal: Noncopyable Structs and Enums
3 Comments RSS · Twitter · Mastodon
I don’t think this is this is the future of App development. if Apple continues on this path I think they will just make third party cross platform frameworks more popular.
I’ve been doing iOS and swift dev for 10 years. I still struggle to even read posts like Jared’s. Swift concurrency has become a very abstract concept.
"Counterintuitive Implicit Actor-Isolation"
wtf is that?
I had a Mac 128K in 1984, and started writing mac (and then ios) apps in the 1990s. C++, ObjC, AppKit, UIKit, etc.
For the last ten years, I have written web apps and now even have a cross-platform version of one of them in development for the Mac.
Yes it uses a "crap-tastic" open-source framework (or some such slur, according to ✊🏻🍆🍏).
But JS promises and async/wait, etc. have worked without just fine for a long time.
And I have never had to worry one bit about "Counterintuitive Implicit Actor-Isolation".
No matter what any Apple shill says, I won't be looking in the rear view mirror.
