Swift Actors: A practical example, part 1

https://trycombine.com/posts/swift-actors/

by tosh • 5 years ago

104 36 5 years ago

danappelxx• 5 years ago

I read earlier versions of the Actor proposal, and maybe I misunderstood, but it seemed like the design was oriented towards UIKit. That’s what made it interesting for me. Has that changed?

Specifically, actors would alleviate the the mental overhead of constant dispatch queue management littering iOS codebases. Certain UIKit classes would gain @UIActor and suddenly you get a compiler error if you try to modify a view from a background thread. I can’t seem to find any references to that in the current proposal.

Regardless, I’m excited for actors to land in the next release. I’m just concerned adoption will be similar to Swift 3’s do/try/catch syntax, which didn’t take off until UIKit converted all fallible synchronous methods from `(Data?, Error?)` to `throws`.

vrtcn• 5 years ago

As far as I know, the new concurrency features can be adopted gradually which would make it very simple for developers to transition from the current completionHandler-based model to the new async/await-based model. Every Obj-C UIKit method with such a completionHandler parameter would from now on be available in two ways from Swift: 1. as usual, with completionHandler 2. new, without completionHandler, marked as ‚async‘ and returning the input types of the completionHandler

Grustaf• 5 years ago

No, interacting with UIKit is just one example usage, though important enough to warrant special constructs like that. The people that seem most excited to me are those that work with server side Swift.

oscargrouch• 5 years ago

From the server side perspective, this Actor implementation is cheap(to develop), safe and more developer friendly.

But i don't know if it will be the most performant implementation as it will depends of how much state copy between threads its involved (as this is the common bottleneck in performance on a multi-threaded implementation).

So a more classic implementation might perform a little better, but i don't know if this will also stand true in Swift as the compiler might use tricks behind the curtains to optimize things giving the people behind this also control the Swift compiler.

tcldr3• 5 years ago

I'm also intrigued where the Actor model will leave Combine. Are they designed to work together?

Many of the Rx based architectures (The Composable Architecture in Swift, React, Cycle.js, etc) that have appeared – all inspired by Elm (itself inspired by Erlang/OTP?) – seem to lean on a kind of pseudo actor model where messages are passed into a kind of 'actor', its state is modified, side-effects are initiated and performed asynchronously, and subscribers are updated in turn.

With the Rx based architectures at least this created a lot of boiler plate and the need to create a separate enum just to pass messages into the monad with a big switch statement to route them all.

Now, if I understand correctly, this actor model would facilitate a very similar workflow but without an additional dependency and far less boilerplate.

Instead of passing messages into the 'actor' via a messages stream – you can just call methods on the actor. Then, an actor can manage a 'state' property internally and simply forward changes to that state to via a publisher (PassthroughSubject/BehaviorSubject).

That would be pretty nice!

jb19914• 5 years ago

all inspired by Elm

No, Elm is just another implementation, not the invention.

weehoo• 5 years ago

What is the invention? Honest question, not familiar with this stuff. Comments make it hard for non-experts to follow the discussion.

tcldr3• 5 years ago

Well, it seems to me that the creators of the mentioned frameworks cite Elm as their inspiration – even if it wasn't the genesis of the concept.

mojuba2• 5 years ago

I'm also wondering whether SwiftNIO will be rewritten to use actors, or it will stay "old-school" for the sake of efficiency. Very much looking forward to Swift maturing for backend development either way.

It's an amazing, rich language with the only drawback of the compiler being shamefully slow (though it's probably not that bad on Linux, where there are no legacy ObjC frameworks). Other than that, I love the idea of having an ARC-based modern type-safe language on the backend, possibly with the new concurrency model being at the core of the network framework.

bsaul• 5 years ago

I've followed the conversations around actors, and i'm really curious to see what the end-result will look like, considering the actor model seems to have been designed independantly from the execution infrastructure. In particular, the concepts of mailbox, executor, etc don't seem to be very apparent so far.

By contrast, i see a lot of talk about actor "isolation", inheritance, reentrancy, etc... Which i don't see mentionned often in erlang / OTP style actor systems...

csharptwdec19• 5 years ago

At a glance this reminds me of something closer to Orleans Virtual Actors than Erlang or Akka.

staticassertion2• 5 years ago

I'm really excited to see what is essentially a mainstream language trying out actors - whatever they end up with, I expect there will be a lot to learn from.

The answer is: “it depends”. It depends how your or others' code uses Person. If two pieces of code, running concurrently, update Person.name at the same time - your app will crash

Damn, I honestly forget what it's like to program with threads in languages that let this happen.

ragnese3• 5 years ago

Why does the author keep saying that the original Person definition can crash the app? That's not true, is it? You'll just get races, as far as I know.

AJRF3• 5 years ago

Assumption but I wonder if the thread sanitiser crashes the app on thread access violations in debug builds so you can debug?

ragnese3• 5 years ago

Ah. Yeah, that could be. I'd still definitely clarify that in the post if that were what they meant.

jmull2• 5 years ago

If you mutate the value “name” is pointing to at the same time from multiple threads, I think you’ll see crashes pretty quickly.

blacktriangle• 5 years ago

So given this example where actor methods are magically syncronous within the actor and async outside of the actor, did Swift solve the whole red/blue functions pain? Or at least seriously alleviate it.

AJRF3• 5 years ago

It uses async/await so they are still coloured functions - which, while coloured, doesn’t make it more painful to call than Non-concurrent methods I guess

jayd16• 5 years ago

It seems more like syntax sugar to easily await synchronous methods on the actor specific task scheduler with a lot of linting thrown in to help you get it right.

In C# you might have to use the following and worry about the private member access yourself.

    await Task.Run(()=>SyncMethod())

mojuba2• 5 years ago

The author mentions "crash" multiple times - is it actually the case when unprotected ARC objects are concurrently accessed? Does it actually crash?

jmull2• 5 years ago

Looking at the Person class in the article, which has just a “name” property with String type…

I think if you mutate that string from multiple threads — like by appending to it — you would get crashes pretty easily.

I’m really not sure if you would see crashes if you simply access and assign to the name property (rather than mutating the value it is pointing to). I have not seen guarantees on this. Maybe I missed it, but if not, even if it appears to work today, it may not tomorrow.

wvdk• 5 years ago

Yes, it does crash if two threads write to a property at the same time. The worst thing about this kind of bug is the inconsistency - often being discovered first by real users. There are also a plethora of shared state bugs that should be reduced with clearer concurrency semantics. All-around big step forward towards Swift's goal of being a "safe" language.

29athrowaway• 5 years ago

Remember, kids: actors are for concurrency. If you do not need concurrency, do not use actors.

ProfHewitt4• 5 years ago

Everybody is going to need concurrency! However, some have yet come to the realization :-(

staticassertion2• 5 years ago

Actors are for isolating state, concurrency is a side effect of that.

ProfHewitt4• 5 years ago

Actors are for communicating with each other. There could easily be billions of Actors communicating with each other in a system.

"One Actor is no Actor."

The fact that "there are no variable races in an Actor" is a side-effect of Actor concurrency.

ProfHewitt4• 5 years ago

Swift Actors need some improvement.

For example, how could Swift Actors implement the following:

    TrainController ≡
             moving := False          // train is initially not moving
             isOpen := False       // door is initially closed

        open ↦  moving ??      // Received request to open door, there are two cases for moving:
             False ↠                 // Case moving=False, then
                   isOpen := True;   // then set isOpen to True and then
                   DoorController.open   // send door an open request in hole of the region 
             True ↠ Throw TrainMoving[] // Case moving=True, then throw TrainMoving

        close ↦ Hole DoorController.close ; // Received request to close door, so send door a close request
                                                          //  in a hole of the region and after door reports that it is closed,
           isOpen := False         // set isOpen to False

        move ↦  isOpen ??                           // Received request to move train, there are two cases for isOpen:
             False ↠                                  // Case isOpen=False, then
                      moving := True;         // set moving to True and then
                      EngineController.move  // send engine a move request in a hole of the region
             True ↠ Throw DoorOpen[ ]     // Case isOpen=True, then throw DoorOpen

        stop ↦ Hole EngineController.stop ; // Received request to stop train, so send engine a stop 
                                                // request in a hole of the region and after engine reports that it is stopped,          
              moving := False         // set moving to False

Swift Actors: A practical example, part 1

Related Stories