I am doing some objective-C / iOS development and have heard several references to the Actor pattern. In Big Nerd Ranch book, it says:
An actor object is used when you have a long running task and some code that needs to be executed after it completes. This kind of object is given the information it needs to perform the task and callbacks to execute when that task is done. The actor runs on its own thread without any further input and is destroyed when it is finished.
The actor here is used in conjunction with a network call. Is this how the Actor is primarily used? Is it mutually exclusive or complimentary to delegation? The Actor definition seems VERY broad and I am trying to get a better handle on what it means. Also, is it possible to have an Actor in a non-OO environment?
The basic Actor Model design pattern is simple. When you hear of an actor, think of it as a computer process or a function. It's some code that you're going to pass a message to, kind of like calling a function. Basically you send the actor instructions and it returns some information back to you.
The actor model can be used as a framework for modeling, understanding, and reasoning about a wide range of concurrent systems. For example: Electronic mail (email) can be modeled as an actor system. Accounts are modeled as actors and email addresses as actor addresses.
The Actor model adopts the philosophy that everything is an actor. This is similar to the everything is an object philosophy used by some object-oriented programming languages, but differs in that object-oriented software is typically executed sequentially, while the Actor model is inherently concurrent.
That definition of an Actor actually seems a little restrictive. It certainly doesn't handle Erlang-style actors (or I believe Scala-style actors). In my experience, an actor is something that:
But fundamentally, an actor is a free-running chunk of code that can receive messages from its environment and can send messages back out to its environment.
Actors are used any time that you need lots (and lots) of stateful little processes. Networking is a common use case, because you don't want to allocate a whole thread to each connection. You want something lighter-weight, so you allocate an actor to each connection, and then schedule the actors on a smaller pool of threads. But networking is certainly not the only use of an actors.
In Erlang, an actor is a function. The function probably tail-calls itself (so it's basically an infinite loop), and it probably has a clean way to self-terminate (the infinite loop has a "break" condition). The loop typically waits for a message from the system, processes it, and then sends out messages to the rest of the system. The Erlang OTP library has some abstractions that eliminate the need to even write the loop, so an OTP actor is implemented as a set of callbacks. In that way, an OTP actor looks a lot like an object.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With