Actor model

The actor model organizes computation around entities receiving messages that express requested behavior. Hewitt, Bishop, and Steiger’s 1973 ACTOR formalism treats control and data flow within one interaction-oriented account.

This view separates a component’s accepted requests from its implementation. The original paper also discusses interfaces, intentions, and scheduling. Those research mechanisms and aims should not be mistaken for automatic performance or correctness guarantees in every practical actor system.

References: [1]

Erlang illustrates message-oriented activities: spawn creates a process and returns its identifier, senders address recipients, and receive selects suitable queued messages. Such Erlang processes are not a one-to-one requirement for operating-system processes.

When the recipient runs, how it changes local state, and whether it replies depend on runtime and application rules. A message interface does not automatically turn the interaction into a synchronous function return.

References: [2] [3]

Ordering is system-specific. Erlang preserves signal ordering from one sender to one destination, without imposing a global order across senders. Selective receive can also skip messages that do not currently match.

Timeouts, process termination, and distribution failures still require request identifiers, replies, and failure rules. Actor-style organization clarifies interaction boundaries but does not alone establish exactly-once external effects or guaranteed message processing.

References: [2] [3]