2.4 Actor events

Although we have so far focused on an actor's ability to send messages to other actors, all the "action" in an actor takes place at the time a message is received. Receiving messages and creating other actors are two examples of events in an actor system.

Events and their relationships illuminate how physical phenomena inspired the actor programming model. For instance, when actor B receives a message from actor A, B can send a message to C as a result, defining an order of arrival events. In this example, which is illustrated in Figure 2.10, the message sent to B caused, or activated, C's arrival event.

Figure 2.10 - B's arrival event activates C's arrival event.

In their seminal paper on the "Laws for Communicating Parallel Processes,"[5] Carl Hewitt and Henry Baker noted that:

Activation is the actor notion of causality... A crude analogy from physics may make activation more clear. A photon (message) is received by an atom (target), which puts it into an excited state. After a while, the atom gives off one or more photons and returns to its ground state. These emitted photons may be received by other atoms, and these secondary events are said to be activated by the first event.

In addition to arrival events and actor creation events, an actor-based system also includes some "initial event" that gets the ball rolling, so to speak. Causality extends to all three types of events: The initial event must precede all other events and may include a set of initial actors. Those actors can process activation events from each other in any order. Finally, and obviously, an actor's creation event must always precede activation events targeting that actor.

Figure 2.11 - Event causality in an actor system.

Figure 2.11 shows that arrival and activation events nicely line up in a time-ordered sequence, one event always occurring before the other. Indeed, we can describe an actor-based computation as a linear ordering of combined arrival and activation events: A computation starts with some event, which is then followed by a finite number of other events, and is finally terminated by the computation's last event. The order of events is strict in the sense that an event can only be influenced by other events that preceded it.

When we say one event occurs before—or after—another event, we intuitively refer to some notion of time. In a sequential computation, when the entire program state is shared globally, the sequence of events that makes up the computation refers to the global time: time shared by all objects participating in the computation. An actor-based system, by contrast, splits the global program state into many local states held by each actor. Those actors interact merely by passing messages, and have no reference to a shared notion of time. Instead, arrival orderings of events in an actor-based system refer to the time local to an actor—there is no requirement to have a notion of global time.

Viewing computations as a partial order of actor events occurring in local time to an actor turns out to be a powerful abstraction. The designers of the actor programming model demonstrated that you can implement any control structure as a sequence of actor events. Because actor-based programming is designed with concurrency assumed, it is theoretically possible to implement any sequential program in a concurrent manner with actor messaging.