SE-0306: Actors

Paulo_Faria · 2021-03-22T17:16:00.321Z

jmjauer:

I disagree. I see it exactly the other way around: Global actors are a retrofit to make classes work with the new actor model. And since classes are the legacy requirement, there is no need for actors to add legacy features.

Yeah, I loved the global actors proposal. In fact, I see it as the nail in the coffin of the argument of compatibility with existing codebase that use classes. Also, I actually see @JJJ's argument in complete opposite light. Given that one can add isolation to existing classes with global actors, effectively turning classes into actors, then there's no reason at all, IMO, to bring inheritance to actors. If you really really want inheritance and isolation, use classes and global actors. I now definitely don't see any reason to bring inheritance to actors.

jmjauer · 2021-03-22T17:17:38.771Z

krawutzi:

Why would you use a class if could use an actor that can do everything a class can (in addition to static concurrency guaranties)?

Classes are not a subset of actors. You can change the state of a class object from multiple threads - you can not do that with an actor. That is the benefit you get from actors - and it is the reason why you can not simply change your classes to actors.

jmjauer · 2021-03-22T17:20:39.659Z

Paulo_Faria:

Yeah, I loved the global actors proposal. In fact, I see it as the nail in the coffin of the argument of compatibility with existing codebase that use classes. Also, I actually see @JJJ's argument in complete opposite light. Given that one can add isolation to existing classes with global actors, effectively turning classes into actors, then there's no reason at all, IMO, to bring inheritance to actors. If you really really want inheritance and isolation, use classes and global actors. I now definitely don't see any reason to bring inheritance to actors.

Holy cow, you are right! Totally missed that.

xwu · 2021-03-22T17:23:26.238Z

JJJ:

But still, as I see it an actor could easily be implemented as a class with a global actor applied.

This is incorrect. See the other thread.

JJJ · 2021-03-22T17:23:26.865Z

Paulo_Faria:

jmjauer:

I disagree. I see it exactly the other way around: Global actors are a retrofit to make classes work with the new actor model. And since classes are the legacy requirement, there is no need for actors to add legacy features.

[..] I actually see @JJJ's argument in complete opposite light. Given that one can add isolation to existing classes with global actors, [..] then there's no reason at all, IMO, to bring inheritance to actors.

I agree it goes both ways

I guess what I'm asking, really, is whether the Swift community wants to add this extra complexity to the language (both specification, implementation, and learning), or perhaps just want to piggyback on the existing "class" type.

Paulo_Faria · 2021-03-22T17:30:15.250Z

jmjauer:

Holy cow, you are right! Totally missed that.

Apparently, what I said is not true according to @xwu in the other thread.

[Pitch] Global actors

This is incorrect. Consider the example of actor BankAccount . Each instance of a BankAccount protects its state from every other instance of a BankAccount . A similar class would not with a global actor applied.

Paulo_Faria · 2021-03-22T17:33:16.603Z

Paulo_Faria:

Given that one can add isolation to existing classes with global actors, effectively turning classes into actors, then there's no reason at all, IMO, to bring inheritance to actors. If you really really want inheritance and isolation, use classes and global actors. I now definitely don't see any reason to bring inheritance to actors.

@xwu this reasoning would be incorrect, then?

JJJ · 2021-03-22T17:58:28.350Z

Paulo_Faria:

@xwu this reasoning would be incorrect, then?

Yeah, I was wrong. As soon as you have more than one instance, this doesn't hold. You would not be able to create a hierarchy of actors where two such "actors" would be truly isolated by each instance having its own execution context. I'm not sure that matters, though. But they would not be real actors.

JJJ · 2021-03-22T18:18:05.567Z

Hmm. Are there any negative consequences of making actors share the same execution context? If a runtime is allowed to run this on a machine without any threading, then everything would basically just run on the MainActor, right? Is that allowed?

So actors would not be able to execute work in parallel, of course. But apart from that?

Is the Swift Concurrency Runtime allowed to merge execution contexts at will? Are there any rules for when that is OK?

michelf · 2021-03-22T18:47:13.418Z

Personally, I'd remove actor and simply replace it with isolated class. We can then rethink of everything in term of isolation alone:

// the class has its own isolation context (it's an actor)
isolated class MyActor {
   func isolatedMember() { ... }
   nonisolated func nonisolatedMember() { ... }
}
// the class is attached to a global actor isolation context
isolated(MainActor) class MyObject {
   func isolatedMember() { ... }
   nonisolated func nonisolatedMember() { ... }
}
// the class has no isolation context, but one of its member is isolated to the main actor
class MyObject {
   func nonisolatedMember() { ... }
   isolated(MainActor) func isolatedMember() { ... }
}

I know nonisolated and global actors where split from this proposal in order to make it simpler, but I'm not sure those splits were warranted. It seems to me we might be slicing things into too many concepts for no good reason, and that it ultimately makes things complicated.

frameworklabs · 2021-03-22T19:44:23.915Z

This is not a bad idea actually!

David_Catmull · 2021-03-22T19:50:59.898Z

For one thing, that solves the inconsistency where "an instance of a class is an object" but "an instance of an actor is an actor".

Paulo_Faria · 2021-03-22T21:17:36.576Z

Could one have an "isolated struct" or an "isolated enum"? What would that mean? As far as I understand we can apply global actors to structs and enums, could one "isolate" any type?

michelf · 2021-03-22T21:41:56.850Z

I don't think isolated struct or isolated enum makes sense because those types are passed by copy. Each actor having access to the value is going to have its own copy so there's no point in each copy having an execution context of its own. It's a bit like asking for indirect class: pointless.

But it does makes sense with global actors, as you mentioned, because the execution context is not part of the struct or enum.

Chris_Lattner3 · 2021-03-23T00:27:46.383Z

michelf:

Personally, I'd remove actor and simply replace it with isolated class . We can then rethink of everything in term of isolation alone:

Structured concurrency provides isolation as well, and both do so by building on SE-0302.

Actors are a declarative frontend to isolation, just as structured concurrency is the procedural interface to them. Calling one or the other the "isolation" system seems misleading and is technically incorrect.

-Chris

michelf · 2021-03-23T01:39:25.505Z

Chris_Lattner3:

Actors are a declarative frontend to isolation, just as structured concurrency is the procedural interface to them. Calling one or the other the "isolation" system seems misleading and is technically incorrect.

Indeed. But I was referring to the upcoming proposals about global actors and nonisolated which are also declarative frontends to isolation. Together actor + @MainActor + nonisolated are three very different ways to spell the same thing: which execution context can run a particular function. (And maybe @Sendable is kind of one too.) Can't we think of a way to make similar things more similar?

frameworklabs · 2021-03-23T10:44:30.359Z

I am wondering if an actor / isolate should have methods after all or if it would be more like a container for objects and you would call methods on exposed objects of it instead. This way it is clear, that an actor is not a class but something different.

DevAndArtist · 2021-03-23T20:16:14.782Z

Would it make sense to look into a possible constraint spelling such as actor protocol Actor: ... {} in the future? Sure the typealias AnyObject = class is still a bit strange, but constraining protocols to type kinds would still be useful for library vendors. I think it would be additive to fix the declaration of the Actor protocol in such a way in the future.

drexin · 2021-03-23T22:55:24.014Z

An actor is not just a synchronization mechanism, it can have functionality of its own. Isolation is only one of the guarantees an actor gives you.

hooman · 2021-03-24T00:55:02.687Z

The key distinction is: You can only exchange Sendable (SE-302) items with an actor. Actor can't expose mutable objects to the outside world, even asynchronously.

In order to protect the mutable state of an object graph with an actor, you need to create a full set of API on the actor to manipulate the object graph. Basically the actor becomes a façade for the object graph.