Актерская модель Эрланга

• это динамичный , функциональный язык; даже больше, чем Clojure в некоторых аспектах.
• В результате он вызывает одиночные присваивания и неизменность : вы не можете изменять существующие переменные, только создавать новые. Все состояния хранятся в стеке в виде вызовов функций и их параметров.
• Параллелизм и передача сообщений поддерживаются на уровне языка как акторы (называемые процессами в Erlang).

Актерская модель

Каждый процесс виртуальной машины Erlang является актером:

• актеры исполняются независимо и общаются только односторонними сообщениями.
• Актеры могут создавать других актеров.
• Когда актер заканчивает свои вычисления, он исчезает.

Как и все парадигмы, модель актора определяется тем, что она отнимает у программиста:

• нет общей памяти между процессами.
• Нет удаленного вызова процедуры : только сообщения, отправленные через асинхронные вызовы.
• В результате не возвращаются значения, поскольку сообщения идут в одном направлении (хотя, конечно, это можно смоделировать с другим отдельным сообщением).

Обратите внимание, что процессы Erlang выполняются внутри одной или нескольких виртуальных машин на одном или нескольких узлах сети, поэтому они не отображаются на процессы ОС.

Эхо-сервер

Не принимая во внимание синтаксис Эрланга, давайте посмотрим на него в действии. Эхо-сервер — это процесс, отправляющий вам обратно сообщения, которые вы ему отправляете.
Этот первый пример будет использован как для изучения внешнего вида и ощущений Эрланга, так и для представления примитивов для создания актеров.

-module(echo).
-export([start/0]).

loop() -> receive
    {Sender, Num} ->
        Sender ! Num,
        loop()
    end.

start() -> spawn(fun loop/0).

This is contained in a echo.erl file, where we define a module named echo. All identifiers starting with lowercase are atoms, while variables start with an uppercase letter. This means Num is a variable, while num would be a constant symbol that cannot be assigned but only passed around (like Ruby symbols or Clojure keywords).

We define two functions loop() and start(), but export only start/0 (the start version with 0 arguments); the complete signature of a function always comprehends its arity (the number of arguments), so start() and start(Variable) would be two different functions.

In loop/0, we use the receive primitive to receive one new message from the queue for this process. We define a pattern for the message — we only accept tuples containing two variables.

After receival, we send back a message to the process identified by the first half of the tuple, containing the number in its second half. We then restart listening by tail recurring on loop() until a new message is delivered.

start/0 is instead a primitive that has to be called from the originating process. It would call spawn/1 to create another process which will execute the loop function; it will then return the control to the calling process.

Here’s how to use this echo server. The shell will be our originating process, while the process for echo will be created:

[giorgio@Desmond:~]$ erl
Erlang R14B02 (erts-5.8.3) [source] [smp:2:2] [rq:2] [async-threads:0] [kernel-poll:false]

Eshell V5.8.3  (abort with ^G)

We compile the echo.erl source file:

1> c(echo).
{ok,echo}

We call start() from this process. Another process is spawned, but spawn() returns its process id. Since it is the last statement of start(), also start() returns the same value, which we can save in a variable. The value of the id is shown, as all other return values of local function calls:

2> Pid = echo:start().
<0.39.0>

Now we send a message to Pid, a tuple containing two values. A tuple is a simple data structure containing a fixed number of values (it is the generalization of a pair or of a triplet):

3> Pid ! {self(), 42}.
{<0.32.0>,42}

Now the other process will handle the message and send one back to us. When we want to receive it, we can invoke receive with an identity handler, just displaying what we have got back:

4> receive Value -> Value end.
42

Let’s complicate this a bit

Let’s try to encapsulate some state into our server. We code a new module called var, which will represent a number we can add to or display.

-module(var).
-export([init/0, add/1, get/0]).

init() ->
    Pid = spawn(fun() -> loop(0) end),
    register(variable, Pid).            % we keep track of the process id

loop(N) ->
    receive
        {add, X} -> loop(N+X);          % we accept more than one type of message: the first has the atom add as the first element for identification
        {Parent, get} ->                % in case of get, before restarting the loop we send a message to Parent with the value
            Parent ! N,
            loop(N)
    end.

add(X) ->                       % these primitives can be called from the parent process, like init()
    variable ! {add, X}.

get() ->
    variable ! {self(), get},
    receive Result -> Result end.

The server has the same structure, but it accepts more than one type of message, distinguishing between them via pattern matching. Moreover, it performs some operations like Parent ! N before tail recurring.

The add/1 and get/0 primitives are meant to be called from the client process, and encapsulate the messages to send to the server process, along with the blocking for receiving results. To manage multiple created processes, we would have to save pids in a list.

Conclusion

As you know, different approaches to concurrency such as functional programming and the Actor model are likely to play a role in the near future due to the rise of parallel and distributed computing. To delve into this new world, I’m currently test-driving a distributed tuple space (like JavaSpaces) in Erlang: the mix of a functional language and the actor model is a big change for an OO developer to deal with.