erlang - erlang可以重用进程ID吗？如果是这样，如何确保正确性？

Question

（1）进程死亡后，是否有可能将其pid重新分配给spawn()创建的另一个进程？

（2）如果是这样，任何通讯安全吗？例如，将回复发送到邮件发件人的Pid。如果发件人已崩溃，我们怎么知道这个Pid现在不属于另一个进程？

（3）pid重用有哪些保证？例如，在重用pid之前是否有最小间隔？

（4）通常如何防止由于pid重用而导致的错误？只是被忽略了吗？

Answer 1

几个问题...


是。 PID可以重复使用。
通信是“安全的”，因为以任何一致性命中重用的PID的机会都非常小。发生网络和硬件错误的可能性远大于此。面对这种情况，我们设计了健壮性的程序，其中包括以可以接受错误消息和/或自发死亡的过程的方式进行编程（这种死亡的代价已计入重启周期）。
对此的保证至少基于我对主要EVM实现的经验（例如，对于HiPE不确定），因为整数分配空间非常大，并且发送消息的速度大大快于整数环绕操作。在大多数情况下。
避免基于PID重用的怪异的关键是将其与其他在典型的使用范围内也是唯一值的东西结合在一起-通常采用Erlang reference的形式。


一方面不至于穷尽，另一方面又不那么花哨地动摇，让我们考虑一个实际的示例：OTP函数gen_server:call/2,3。

当您使用gen_server:call/2,3时，gen_server模块除了监视正在发送消息的进程外，还会生成一个类似于{self(), make_ref()}的组合消息标签。发送过程至少可以保证，如果正在调用的过程在发送答复之前已死，则将收到监视器退出消息而不是响应，并且垂死进程的PID将与刚刚调用的进程匹配。正在接收消息的接收过程将同时接收发件人的PID和保证本地唯一的Erlang引用（至少在相当长的时间内-我相信唯一性的空间在数十亿左右）。 。当它发送响应时，接收过程还必须知道该参考以及由最初用于发送的PID进行寻址。

发送进程可能已经死亡，并且可能已经使用相同的PID重新生成了一个新进程（尽管极不可能），但是使用相同PID生成另一个进程并阻塞在一个进程上几乎是不可能的。 gen_server:call/2,3消息恰好具有与旧的死调用相同的内部运行时引用。

除了这种几乎不可能的事情之外，让我们考虑一个世界，在这个世界上实际上发生了一件完全奇怪的事情，所有保障措施都失败了……

（按2^64 * 2^64 * chance_of_failure_on_this_tiny_scale()的顺序）

发送过程将得到一个奇怪的响应消息，几乎可以肯定的是断言匹配失败并在下一行终止，然后以已知状态重新启动。同一问题发生两次的机率可能低于质子在接下来的几分钟内衰减的可能性。

这是“正确性”吗？不。在大规模并发系统中，没有可证明的正确性。这就像试图“证明”一个代表全人类的方程式一样。大多数Erlang系统本质上都是混乱的，因此通常不适合作为系统的证明。您可以证明单个的纯函数是正确的，并且副作用过程在其生命周期中可能调用的所有函数都具有确定的终止条件，其中包括对不稳定数据的崩溃。最后一部分是Erlang如何实现系统的强大鲁棒性（很好的编码实践，对功能原理的遵守以及使用Dialyzer的良好文化也有很大帮助）。

因此，“正确性” ...尽可能地在功能上证明这一点。很好，为什么我们要使用PropER和QuickCheck之类的工具。作为一般准则，请尽力编写：


尽可能纯净的功能。使副作用代码在代码中尽可能与纯代码隔离，该纯代码仅计算和返回值。
可证明是可崩溃的进程。使每行上都有一个=。这就是为什么Erlang的=是赋值，声明和统一在一起的原因。
具有可证明状态的协议。例如，您不能使两个相同的进程以阻塞的方式相互调用，而没有死锁的风险。这是并发系统的基本限制。 CAP定理是另一个定理。针对这些约束（奇怪地解放）来设计系统，并有意识地选择权衡取舍。


除非您在学术界，否则以比函数更大的规模进行证明是傻瓜的事（该函数可能在下面称为巨大的事物世界，因此，这实际上并不是一个很大的限制）。也可以为不可能或锁定的条件提供证明协议，如果有时间，可以继续这样做（否则，我们其余的凡人将做这些，并坚持超时并重做过去在调用时实际上已超时的代码-这不应该是经常发生的事情。

话虽如此...史蒂夫-O几乎可以肯定地说，在未来两年内，它将跨越数据中心中的数据电缆跳闸，并且将集群分裂的次数比任何人都可能看到的PID缠绕会导致实际冲突的情况要多。未来十年。