Actor pattern - what it exactly constitutes
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?
Answer
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:
- Sends and receives messages (each actor has a mailbox)
- Shares no mutable memory with other actors
- Is scheduled based on the whims of the runtime. An actor could be given its own thread, but it is more likely that several actors participate in co-operative multithreading in a single thread, or maybe even participate in pre-emptive multithreading.
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.