trap_exit EXIT msg 和 common msg 之间的竞争条件答案

【问题标题】：Race condition between trap_exit EXIT msg and common msgtrap_exit EXIT msg 和 common msg 之间的竞争条件
【发布时间】：2013-01-29 00:57:14
【问题描述】：

您好，问题如下：假设我们有链接的进程 A 和 B。进程的 A 标志 trap_exit 设置为 true。让 B 进程向 A 发送一个 msg 然后退出：

PidA ! 'msg',
exit(reason).

我想知道我们是否可以确定进程 A 将收到 'msg' 并且只有在它 {'EXIT', Pid, reason} 之后才会出现？我们可以预测消息的顺序吗？我在文档中找不到任何证据，但我想它会这样工作，但我需要一些证据。不想在这里有比赛条件..

【问题讨论】：

标签： erlang

【解决方案1】：

至于不要让这个问题悬而未决。这是 erlang-questions 邮件列表中的讨论：

长话短说：所有消息都是信号（或所有信号都是消息），退出被视为来自进程的消息，保证以它们发送的相同顺序到达。

【讨论】：

【解决方案2】：

对我来说，这听起来像是一种代码味道。为什么需要依赖trap_exit？您是否考虑过替代方案，例如适当的监控？

【讨论】：

我不认为依赖trap_exit是不恰当的监控。由于 msgs 排序是可预测的（在文档中提到）我只想知道 dois 对于上述情况仍然如此。
好吧，你不能捕获kill 信号（参见stackoverflow.com/questions/13134078/can-i-trap-exitself-kill）。
你在使用 OTP 行为吗？
我知道 kill 信号，是的，我使用 OTP。我只对上面的问题感兴趣。无论如何感谢您试图告诉我我错在哪里。
对于这类事情，你也应该考虑使用Mref = erlang:monitor(process, Pid)。通常使用监视器更安全，并且您不必设置出口来使这些工作正常进行。在 OTP 中，设置trap_exit 的唯一真正原因是如果您想清理某些东西保证，即使主管杀了您。避免这样做通常是好的风格。

【解决方案3】：

我有 O'Reilly Erlang 编程书在这里，在第 4 章的消息传递部分，它说：

邮件按投递顺序存储在邮箱中。如果两条消息从一个进程发送到另一个进程，则保证消息按照发送的顺序被接收。但是，此保证不会扩展到从不同进程发送的消息，并且在这种情况下，排序取决于 VM。

但是，在您的情况下，我不确定退出消息是否真的来自进程 B。它可能源自 VM 内部的某个地方。如果我想确定，我实际上会让进程 A 在收到您的通知消息时触发进程 B 的退出。

【讨论】：

是的，我读过这本书，我记得它，但没有提到关于信号的内容。最后我在官网erlang.org/download/erl_spec47.ps.gz找到了erlang草稿（第10.6段），并且根据草稿消息内部是信号。由于来自单个进程的信号的顺序是可以预测的，我们也可以说一下我的情况。