SE-0316: Global Actors

[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