liveBook · Manning

Actor

As explained in Functional Design and Architecture: Examples in Haskell

A concurrent actor is an independent computational entity that receives requests, updates private state, and produces responses or effects.

An actor is an independent, stateful part of a reactive application. It has a lifetime, public interface, and specified behavior; it receives work through a communication protocol rather than exposing the environment in which it runs. Actors may be processes, threads, lightweight threads, or separate machines, depending on deployment constraints. section 8.1.1

Use actors when formulas or devices must continually react to incoming data instead of producing one precomputed answer. In a spaceship simulator, sensors emit measurements, controllers calculate commands, and navigation adjusts a route; each component can evolve independently while participating in a larger system. section 8.1 section 8.1.1

The important boundary is the protocol. A request-and-response contract hides whether actors communicate through a message broker, database, event bus, TCP/IP, or an in-process mechanism. This separation lets a virtual simulator resemble a real distributed environment without making individual actors depend on its orchestration. section 8.1.1

A simulator actor illustrates a practical request protocol:

  • Run a finite simulation and return its result. section 8.2.1
  • Start a simulation that continues without an expected result. section 8.2.1
  • Shut down the simulator and complete a shutdown response. section 8.2.1

Request–response simulator

Place the simulator worker in its own thread and give it an MVar containing requests. A caller creates an empty result MVar, sends RunSimulation with that MVar attached, and waits for the worker to run the logic and fill the result. Pairing each request with its response makes the expected result type part of the protocol. section 8.2.1

Actors organize stateful concurrent applications, but safe and reliable interactions cost design effort. MVars can provide orderly shared access and a type-safe request–response service, yet large MVar-based models can become awkward and overcomplicated; STM is a possible next step when the concurrency model grows. section 8.3

Figure 8.6 Simulator as an actor

Inspect the simulator boundary as an actor separated from the application by its request protocol. section 8.2.1

How Functional Design and Architecture: Examples in Haskell covers it

How deep it goes
Defines actor properties and develops a threaded simulator actor with an MVar request–response implementation.
Examples
Uses spaceship sensors, controllers, navigation devices, and a simulator supporting run, start, and shutdown requests.
What it assumes
Builds on prior state handling while applying concurrent state through actors and MVars.
What you can do after
Build it from scratch as a threaded simulator actor using an MVar request–response protocol.
How it connects
Connects actors with reactive programming, concurrency, MVars, request–response protocols, message queues, and STM.

Also explained in

Compare how 7 books explain actor →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Functional Design and Architecture: Examples in Haskell. The section links point to the parts of the book it draws on.