SE-0316: Global Actors

[Chris_Lattner3 (Chris Lattner)]

@Chris_Lattner3

• Reject them as a compile time error. This will have massive source breakage and isn't a very friendly model.
• Codegen their accessors to produce a runtime error when accessed from a Task (either structured or actor), but allow access from pthreads an other legacy code. This is source compatible and provides progressive migration path, but is a footgun. However, this will be a much easier to detect and fix problem than optional unwraps and array out of bound errors that cause similar traps.
• We could codegen their accessors into implicitly async accessors, sort of treating each global variable as if it is on an anonymous global actor. This would also be a major source break (because you would only be able to touch these in async functions) but would provide nice model over time.
• We can codegen globals to be uninherited unstructured task local values, which don't require @Sendability . This would fill in a hole in the design space but more importantly, would provide full source compatibility for Swift concurrency. They do have somewhat new semantics that we'd have to teach, but I think the benefits outweigh the costs.

I added a fourth option to the list above, which I think is also worth discussing. In any case though, I think that the exact fate of Swift global variables is both complicated and separable from the base "Global Actors" proposal here, and should likely be split to its own discussion.

-Chris

[Douglas_Gregor]

@gwendal.roue

@Jumhyn

If you're not writing await , the access is synchronous. ... But from the same global actor, users "can" write a synchronous call and have it compile.

I see what you mean. Yes, this looks like a guarantee indeed, thank you!

Maybe the proposal authors will add extra information, around the fact that we also need synchronous guarantees in the interaction between @MainActor code, and other code that happens to run on the main executor.

I feel like synchronous guarantees between @MainActor code are well-covered, since they're identical to synchronous access in the general actor model. What "other code that happens to run on the main executor" are you thinking about? The operation passed to DispatchQueue.main.async? Objective-C code?

@Chris_Lattner3

The approach described in Defining Global Actors is very sensible. What is done to prevent creating other instances of the actor? I think we need to prevent this somehow (for memory safety), perhaps with a dynamic check?

We're not doing anything to prevent other instances of the actor, and I'm not sure we need to: only the instance returned by shared is special. One could presumably create some kind of shared implementation that produces a unique actor instance at each call, and we'd lose the guarantee that everything is getting serialized properly, but that doesn't seem like something we should defend against.

@Chris_Lattner3

In Using global actors on functions and data, it makes total sense to be able to mark methods as pinned onto an actor. How does this interact with API resilience/evolution?

You can't add a global actor annotation because you'll break any caller that isn't on that global actor. Removing a global actor annotation is okay in some cases---but not from anywhere that one could infer from. The proposal states a more restrictive requirement because the latter is a bit hard to describe well:

A global actor attribute (such as @MainActor) can neither be added nor removed from an API; either will cause breaking changes for source code that uses the API.

@Chris_Lattner3

Can protocol requirements be marked as @MyGlobalActor ? (later: yes apparently according to the inference section). It would be great to mention this earlier in the proposal.

Sure, I'll update the protocol text.

@Chris_Lattner3

In Closures, I'm not sure I understand the last bit:

If a closure is used to directly initialize a parameter or other value of a global-actor-qualified function type, and the closure itself does not have a global actor explicitly specified on it, the closure will have that global actor inferred. For example:

@MainActor var globalTextSize: Int

callback = {
globalTextSize = $0 // okay: closure is inferred to be isolated to the @MainActor
}

Are you saying that the @MainActor aspect is inferred from the type of callback or are you saying that it is inferred from the type of globalTextSize which happens to be uttered inside the closure?

The former. Without this inference, the write to globalTextSize would be ill-formed.

@Chris_Lattner3

Global and static variables not annotated with a global actor can effectively be accessed from any concurrency context, and as such are prone to data races. To eliminate these data races, we can require that every global or static variable do one of the following:

• Explicitly state that it is part of a global actor, or
• Be both immutable (introduced via let ) and non-isolated.

This allows global/static immutable constants to be used freely from any code, while any data that is mutable (or could become mutable in a future version of a library) must be protected by an actor.

The phrasing "we can require" makes it sound like a decision hasn't been made here, and this is a key part of the design that has to be nailed down.

The intention of the proposal is to require this, but it's a point that absolutely needs discussion. I think the issue of unannotated global/static variables is large enough that we should subset it out.

@Chris_Lattner3

What is the proposals model for playgrounds and scripts? We obviously shouldn't have boilerplate annotations like @MainActor on every top level variable. How does this work / how does the proposal handle this?

Unclear! The current model of "global" variables in playgrounds and scripts isn't even memory safe without concurrency in the mix, so we need a larger rethink here. If we treat global variables within scripts/playgrounds as if they were locals, there's nothing to do because they fall under the local capture rules.

Unrelated to any of the above, @John_McCall and I were talking about turning the ad hoc protocol for global actors into a formal protocol, e.g.,

protocol GlobalActor {
  associatedtype ActorType: Actor
  static var shared: ActorType { get }
}

It helps formalize the relationship between global actors and actors. We'd then extend the protocol with custom executors to eliminate the "hop" through the actor, e.g.

protocol GlobalActor {
  associatedtype ActorType: Actor
  static var shared: ActorType { get }
  static var sharedUnownedExecutor: UnownedExecutorRef { get }
  // note: we require that shared.unownedExecutor == sharedUnownedExecutor
}

Doug

[anandabits (Matthew Johnson)]

@Douglas_Gregor

Unrelated to any of the above, @John_McCall and I were talking about turning the ad hoc protocol for global actors into a formal protocol, e.g.,

I think we should use a formal protocol for global actors and suggested it in response to the first pitch [Pitch] Global actors - #6 by anandabits. This would ideally allow code to be written that is generic over global actors:

@MyActor
class MyClass<MyActor: GlobalActor> { ... }

I have a pre-existing library that uses a coarse-grained actor approach where many actor-bound objects run in the context of a single actor. This is encoded in the type system such that objects sharing an actor can be composed while those in the context of different actors cannot. The above generic global actor technique should make a straightforward port of the library to Swift’s actor system possible.

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

@Douglas_Gregor

protocol GlobalActor {
  associatedtype ActorType: Actor
  static var shared: ActorType { get }
  static var sharedUnownedExecutor: UnownedExecutorRef { get }
  // note: we require that shared.unownedExecutor == sharedUnownedExecutor
}

That protocol looks good!

Would we'd provide a default impl for sharedUnownedExecutor right? (shared.unownedExecutor)

[gwendal.roue (Gwendal Roué)]

@Douglas_Gregor

What "other code that happens to run on the main executor" are you thinking about? The operation passed to DispatchQueue.main.async ? Objective-C code?

Yes, everything which is not marked @MainActor: UIKit callbacks and overridden methods, existing libraries and code bases. I don't quite have a clear idea of the amount of @MainActor annotations that will have to be added, and the amount of interfaces that will have to create suspension points, and potential loss of critical synchronous calls.

[gwendal.roue (Gwendal Roué)]

I have another question. The code shipped in the wild is littered with dispatchPrecondition(condition: .onQueue(.main)) and assert(Thread.isMainThread).

Is there any risk that those assertions are trigged by code that runs on the main actor? Is there a recommendation for developers of libraries whose APIs can talk to both clients who use the main actor, and clients whose code can't use the new runtime (how to rewrite those assertions in a way that is compatible with both environments)?

[Douglas_Gregor]

@anandabits

@Douglas_Gregor

Unrelated to any of the above, @John_McCall and I were talking about turning the ad hoc protocol for global actors into a formal protocol, e.g.,

I think we should use a formal protocol for global actors and suggested it in response to the first pitch [Pitch] Global actors - #6 by anandabits. This would ideally allow code to be written that is generic over global actors:

@MyActor
class MyClass<MyActor: GlobalActor> { ... }

I am so sorry that I missed/forgot that you had brought this up before! Name lookup for @MyActor looking within the generic parameter list that comes later is a little bit odd, but this seems like a powerful pattern for custom attributes in general and I think it does make sense here.

@ktoso

Would we'd provide a default impl for sharedUnownedExecutor right? ( shared.unownedExecutor )

Yes.

@gwendal.roue

@Douglas_Gregor

What "other code that happens to run on the main executor" are you thinking about? The operation passed to DispatchQueue.main.async ? Objective-C code?

Yes, everything which is not marked @MainActor : UIKit callbacks and overridden methods, existing libraries and code bases.

(Objective-)C entities can be marked as being on the main actor with, e.g., __attribute__((swift_attr("@MainActor"))). It's not enforced from the Objective-C side, of course, but it lets C APIs make the promise that they'll always be used from the main thread.

@gwendal.roue

I have another question. The code shipped in the wild is littered with dispatchPrecondition(condition: .onQueue(.main)) and assert(Thread.isMainThread) .

Is there any risk that those assertions are trigged by code that runs on the main actor?

@MainActor code always runs on the main thread/main queue. When you await because you're referencing a @MainActor entity from a non-@MainActor context, it's doing a DispatchQueue.main.async.

@gwendal.roue

Is there a recommendation for developers of libraries whose APIs can talk to both clients who use the main actor, and clients whose code can't use the new runtime (how to rewrite those assertions in a way that is compatible with both environments)?

Within the confines of this proposal, the only recommendation is "add a new @MainActor API and deprecate the old one". The implementation actually has some affordances for the use case you describe---essentially, it one can state that an API should be on the main actor, but only enforces that property from other code that has adopted Concurrency features (actors, async, whatever). We were planning to bring up those ideas to make it easier to evolve toward concurrency in a separate discussion thread, later, to tackle interoperability between pre-Concurrency and Concurrency code holistically.

Doug

[gwendal.roue (Gwendal Roué)]

Thank you

[filip-sakel]

@Douglas_Gregor

Unrelated to any of the above, @John_McCall and I were talking about turning the ad hoc protocol for global actors into a formal protocol, e.g.,

protocol GlobalActor {
  associatedtype ActorType: Actor
  static var shared: ActorType { get }
}

It helps formalize the relationship between global actors and actors. We'd then extend the protocol with custom executors to eliminate the "hop" through the actor, e.g.

protocol GlobalActor {
  associatedtype ActorType: Actor
  static var shared: ActorType { get }
  static var sharedUnownedExecutor: UnownedExecutorRef { get }
  // note: we require that shared.unownedExecutor == sharedUnownedExecutor
}

I’m also +1 on the GlobalActor protocol, but wonder if we’d be able to write:

struct T<Actor: GlobalActor> { 
  @Actor a: Int
} 

Other than that, the feature looks very well thought out! I can't wait for it to land in an official release!

[beccadax (Becca Royal-Gordon)]

Sorry to double-post, but two thoughts on this section:

A closure can be explicitly specified to be isolated to a global actor by providing the attribute prior to the in in the closure specifier, e.g.,

callback = { @MainActor in
  print($0)
}

callback = { @MainActor (i) in 
  print(i)
}

1. There's no formal grammar specification in the proposal, so it's not clear: if the closure has a capture list, does it come before or after the attribute? (I think I may have brought this up once on Twitter or something; it must have been lost in the shuffle.)

2. Can we extend this to other attributes that can be applied to closures, in addition to global actors? Result builders are the one that comes to mind immediately, but @Sendable and @escaping might also be useful in niche situations. (Maybe we should sever this from the global actors proposal, though.)

[Douglas_Gregor]

@Douglas_Gregor

We were planning to bring up those ideas to make it easier to evolve toward concurrency in a separate discussion thread, later, to tackle interoperability between pre-Concurrency and Concurrency code holistically.

Just to follow up on this, I've posted a writeup on how to manage the incremental rollout of Concurrency throughout the ecosystem, which provides some affordances for handling both pre-Concurrency and Concurrency-adopting clients. Let's chat details over there.

Doug

[EDIT: Added the link to the writeup.]

[Joe_Groff]

Thanks everybody for your feedback during this review. The core team has returned the proposal for another round of revision.