如何“成为”？用支持参与者模型的语言实现？

Question

Gul Agha 在他的技术报告“Actors：分布式系统中的并发计算模型”中很好地描述了 Actor 模型。

在第49页他解释了“成为”命令：

become <expression>

在调用“成为X”后，一个演员会将他所有的消息转发到另一个演员的邮箱（X）。

然而，我不确定这是如何在 Erlang 和 Scala 等语言中实现的（它根本就实现了）。我必须手动编码吗？那效率呢？ Agha 展示了使用消息传递的堆栈实现。每次执行弹出或推送时，都会向某个参与者添加一个转发链接...经过数十万次操作后，我预计这样的实现会花费太多时间转发消息而不是执行实际工作，除非某些在幕后进行了很好的优化。

所以我的问题是：如何在 Erlang、Scala（以及其他语言的库）等典型 Actor 语言中实现转发（或“成为”）？

Answer 1

它没有直接在 Erlang 中实现，但您可以编写一个简单的 become 函数来接收消息，将其转发到另一个进程，然后调用自身：（

become(Pid) ->
    receive
        Msg -> Pid ! Msg
    end,
    become(Pid).

工业强度版本可能需要处理信号和其他零碎的东西，但这就是它的本质。）

调用 become(Pid) 将有效地将调用进程从外部世界转变为进程 Pid看法。

这并不能解决您强调的问题，重复调用 become 会导致转发链的增长。然而，这在 Erlang 中通常不会发生，而且我不确定 Erlang 的进程如何映射到 Actor 模型上。

Answer 2

Actor 是一个逆变协函子，因此“成为”就是 comap。

换句话说，T 类型消息上的 Actor 基本上是类型的函数 (T => Unit)。这只是函数组合（也许带有恒等函数）。

它是在 Scalaz 中实现的：

val a1 = actor(a => println(a))
val a2 = a1.comap(f)

参与者 a2 将 f 应用于其消息，然后将结果发送到 a1。

Answer 3

在这里选择 Erlang。

在基本层面上，有两种选择。如果您只想使用 become 来更改给定进程的行为（请参阅第 2.1.3 节列表中的第 2 点），那么只需使用不同的递归函数：

loop(State) ->
     receive
          {normal, Msg} -> loop(State);
          {change, NewLoop} -> NewLoop(State)
     end.

假设 NewLoop 是一个高阶函数，每当您将消息 {change, NewLoop} 发送到最初运行函数 loop/1< 的进程时/code>，然后它将使用 NewLoop 作为其定义。

第二个选项是您希望进程充当代理（并更改行为）的选项。这与马塞洛·坎托斯的建议类似。只需让进程循环并将消息转发给新进程（窃取他的代码）：

become(Pid) ->
    receive
        Msg -> Pid ! Msg
    end,
    become(Pid).

---

理论上，这符合论文的要求。但实际上，在现实生活中的 Erlang 系统中使用第二种选择是存在风险的。在两个进程之间的通信中，一个常见的概念是使用发送者的进程标识符“标记”消息，并且回复将使用接收者的进程标识符进行标记。可以完成以下消息的交换（这不是代码，只是手写符号）：

A = <0.42.0> <-- process identifier
B = <0.54.0>,
A: {A, "hello"},
B: {B, "hi"},
A: {A, "how are you?"}.
B: {B, "Fine!"}.

因此，当 A 期望来自 B 的消息时，它将能够匹配仅通过使用诸如 {B, Message} 之类的模式来实现这些。在转发消息的情况下，该寻址方案变得无效并且简单地被破坏。

另一种方法是使用引用 (make_ref()) 作为寻址方案来匹配返回 Pids 之上的消息。这将通过使用两个不同的实体将 Pid 作为地址和标识符的使用分开。

即使寻址是安全的，还有另一个问题：进程依赖性。命名进程、崩溃进程、监视器等会发生什么？客户端进程可能有监视器、链接等所有设置，以确保在没有通知的情况下不会出现任何问题。通过修改路由进程以捕获退出信号并转发它们，应该可以使事情变得更安全：

loop(State) ->
     receive
          {normal, Msg} -> loop(State);
          {become, Pid} ->
              process_flag(trap_exit, true), % catch exit signals as messages
              link(Pid),                     % make it so if one process crashes, the other receives the signal
              become(Pid)
     end.

become(Pid) ->
    receive
        {'EXIT', Pid, killed} -> exit(self(), kill);  %% uncatchable termination
        {'EXIT', Pid, normal} -> ok;                  %% die normally too
        {'EXIT', Pid, Reason} -> exit(Reason);        %% die for the same reason as Pid
        Msg -> Pid ! Msg                              %% forward the message
    end,
    become(Pid).

这个经过测试的代码应该更安全，因为依赖于第一个进程的进程将获得与 表示的错误消息相同的错误消息中的Pid变成(Pid)，使得路由相当透明。但是，我不保证这从长远来看可以在现实生活中的应用程序中发挥作用。

尽管它是可能的并且在概念上足够简单来表示和执行诸如“成为”之类的事情，但 Erlang 的标准库并没有真正考虑到第二个用例。对于现实世界的应用程序，我只能推荐第一种方法，目前存在的每个 Erlang 应用程序都广泛使用该方法。第二个不常见，可能会导致问题

---

_{^**上一个示例中对函数 become/1 的调用可能应该是 ?MODULE:become (Pid) 以避免将来与热代码加载相关的潜在崩溃。 *}

Answer 4

请参阅 Agha 论文“Actors: A Model of Concurrent Computation in Distributed System”的第 12 页（我拥有的 PDF 副本的第 26 页）。 “成为”是他的演员语言，你如何指定#2，即演员的新行为。将消息转发给另一个参与者只是许多可能的新行为之一。

我认为，如果您想要转发行为，那么对于 Scala Actor，您基本上与 Erlang 处于同一条船上。在幕后，Scala“react”和“reactWithin”的工作方式很像become，因为react块定义的部分函数是actor的新行为，但我不确定这种相似性是否是故意的。

大多数（全部？）“演员”实现与 Hewitt 的演员模型和 Agha 的演员语言有相当大的偏差。 IIRC 在 Agha 语言中指定演员行为的语言部分甚至不是图灵完备的。只有当您考虑参与者的配置时，整个语言才变得图灵完整。我想说 Actor 模型和当前 Actor 框架之间的关系有点像 SmallTalk 中的面向对象与 C++ 中的面向对象的关系。有一些概念转移和类似的术语，但在细节上它们非常非常不同。

Answer 5

Akka 的 Actor 有一个“HotSwap”概念，您可以将新的 PartialFunction 发送到 Actor 来替换其现有的消息处理程序。前一个会被记住并且可以恢复。在 http://doc.akkasource.org/actors 详细信息。