you might expect that @MainActor functions can be called on arbitrary threads.
(I know it to be true)
But that's explicitly what the compiler is trying to stop, and is also what many users think is guaranteed not to happen. (and indeed what Apple videos promise)
Given the almost complete lack of documentation around @MainActor - it's not very surprising that people don't know what it does.
Still - the fact that the compiler will object if the variable is not marked @MainActor even though it doesn't enforce the @MainActor-ness is at the very least misleading
struct ContentView: View {
var body: some View {
//Button just updates the binding when clicked
//But on a background thread
BoundButton(val:binding)
}
@MainActor
var binding:Binding<Bool> {
//The Binding is created on @MainActor
return Binding<Bool> {
return true
} set: { _, _ in
//But the setter could be called from any thread
//So the compiler shouldn't allow this call to
//@MainActor annotated shouldBeOnMain
//Error generated here if variable is -not- marked @MainActor
//Call to main actor-isolated instance method 'shouldBeOnMain()' in a synchronous nonisolated context
shouldBeOnMain()
}
}
@MainActor
func shouldBeOnMain() {
if !Thread.isMainThread {
fatalError("Not on Main!")
}
}
}
struct BoundButton: View {
@Binding var val:Bool
var body:some View {
Button {
Task.detached {
val = false
}
} label: {
Text("TryMe")
}
}
}
I was merely pointing out that while it's far from ideal, at least this situation is handled correctly:
struct BoundButton: View {
@MainActor @Binding var val: Bool
var body:some View {
Button {
Task.detached {
val = false // š Main actor-isolated property 'val' can not be mutated from a Sendable closure
DispatchQueue.main.async {
val = false // ok
}
}
Task.detached { @MainActor in
val = false // ok
}
} label: {
Text("TryMe")
}
}
}
I would have expected a compilation error in this code when compiling under strict concurrency checking (which will be enabled by default in Swift 6). However, it appears that even under strict concurrency checking, this isn't being diagnosed.
I would expect it because the parameters passed to Binding.init(get:set:) are not main-actor isolated. The set closure declared here seems to be inferring @MainActor isolation from its declaring context, but it is being passed off to Binding.init(), which doesn't promise to fulfill that contract.
Is it expected that a @MainActor closure can be passed to a non-actor-isolated argument?
I think this is āokayā because the closure is formed on the main actor and is not marked @Sendable so it Should be impossible for the formed function reference to be handed off to a different isolation context and executed there.
That thatās happening seems like a bug internal to SwiftUI to me but I donāt think itās a problem in the client code, unless Iām missing something.
the compiler doesn't know anything about where this closure is going to be run.
(The Binding API gives no guarantees) so, it makes zero sense that the compiler is assessing correctness on the basis of the enclosing function's isolation.
Function values default to non-Sendable, so this signature implicitly promises that get and set won't cross an isolation domain. If Binding allows that to happen internally, then either the interface is misrepresented (and these values should be @Sendable) or there's an implementation bug that violates the concurrency rules.
This can be reproduced locally fairly easily. On its own, the following is fine:
func f(_ h: @escaping () -> Void) {}
actor A {
var x: Int = 0
func g() {
f {
self.x += 1
}
}
}
but if the body of f is changed to:
Task.detached {
h()
}
then we get a warning that a non-Sendable closure is being captured by a Sendable closure. If we mark h as @Sendable, then we do get an error at the call site of f:
test.swift:12:18: error: actor-isolated property 'x' can not be mutated from a Sendable closure
self.x += 1
^
test.swift:9:9: note: mutation of this property is only permitted within the actor
var x: Int = 0
^
Are you saying that if I write a library that has a callback (just a regular escaping function) - then somehow the library code needs to know what isolation domain the callback was created in - and ensure to only call it in that domain?
That seems kinda weird if so. How would my library even know what isolation domain the callback was created in? I just saved it to a variable, then called it at a later point...
Well, yes and no. It doesn't need to know which specific isolation domain the callback was created in, but if it's a non-sendable function then the callee does know that the function was created in the current isolation domain (because non-sendable functions can't cross isolation domains). So what the callee is responsible for ensuring is that the function doesn't leave the current isolation domain, which should be covered by sendability checking. Moving a non-sendable function (or any non-sendable value) to another isolation domain is invalid.
The problem here is not with the Binding ā which isnāt Sendable and should not be ā but with Task.detached { val = false }, which improperly captures the Binding in a non-@Sendable closure, and this is correctly diagnosed with full strict concurrency checking. I personally think this should be an error rather than a warning, but
In the end I traced this crash to something related to the Secure Enclave ECC encryption that Iām working with, but then it was inadvertently resolved by another fix that I implemented, and that other fix may well have had an effect on the interweaving of background and @MainActor methods. I donāt know to what extent Secure Enclave encryption may involve the Objective-C-related things that expose one to these @MainActor foot-guns, but I just wanted to post this here in case the information Iāve provided sparks any helpful feedback in response, because inadvertently fixing a completely cryptic crash that reproduces 100% of the time on my bossā TestFlight instance and 0% of the time on my devices is unsettlingā¦
be impossible for the formed function reference to be handed off to a different isolation context and executed there.