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

（1）在一个进程死亡后，它的

pid

是否可能被重新分配给另一个由

spawn（）

创建的进程

（2）如果是，任何通信如何安全？例如，向消息发送者的

Pid

发送回复。如果发送方崩溃了，我们怎么知道这个

Pid

现在不属于另一个进程

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

---

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

很多问题

对。PIDs可以重用

通信是“安全的（ish）”，因为以任何一致性达到重复使用的PID的机会是无穷小的。打击网络和硬件错误的可能性远远大于此。面对这种情况，我们设计的程序具有健壮性，其中包括以能够接受错误消息和/或进程自发死亡的方式进行编程（这种死亡的成本包含在重启周期中）

它的保证是基于这样一个事实的，至少从我在主要EVM实现中的经验来看（例如，对于HiPE不确定），即整数分配空间非常大，并且在大多数情况下发送消息的速度远远快于整数包装

避免基于PID重用的怪异的关键是将其与其他在典型使用范围内也是唯一价值的东西结合起来，而这些东西通常具有

一方面没有穷尽，另一方面不太迂腐，让我们考虑一个实际的例子：OTP函数。

使用

genu-server:call/2,3

时，genu-server模块会生成一个类似于

{self（），make_-ref（）}

的组合消息标记，此外还会监视发送消息的进程。发送进程被保证，至少如果它调用的进程在发送应答之前死亡，那么将接收监视器退出消息而不是响应，并且死亡进程的PID将与它刚才调用的PID匹配。接收消息的接收进程将同时接收发送方的PID和保证本地唯一的Erlang引用（至少在相当长的一段时间内——我相信唯一性的空间在数十亿的某个地方）。当它发送其响应时，接收进程还必须知道该引用，并由最初用于发送的PID寻址

发送进程可能已死亡，新进程可能已使用相同的PID重新启动（尽管可能性极低），但是，几乎不可能用相同的PID生成另一个进程，并且阻塞

genu server:call/2,3

消息，该消息恰好与旧的死调用具有相同的内部运行时引用

除了这个几乎不可能的事情，让我们考虑一个世界，在这个世界里，一个完全奇怪的事情发生了，所有的安全措施都失败了…… （在这个极小的刻度（）上，

2^64*2^64*发生故障的概率

发送进程将收到一条奇怪的响应消息，几乎可以肯定，断言匹配失败并在下一行死亡，然后在已知状态下重新启动。同样的问题发生两次的几率可能比质子在接下来几分钟内衰变的几率要低

这是“正确”吗？不，在大规模并发系统中没有可证明的正确性。这就像试图“证明”一个代表全人类的方程式。大多数Erlang系统本质上都是混沌的，因此通常无法作为系统进行验证。您可以证明的是，单个纯函数是正确的，并且副作用进程在其生命周期内可能调用的所有函数都有明确的终止条件，包括对不可靠数据的崩溃。最后一部分是Erlang如何作为一个系统实现如此强大的健壮性（好吧，良好的编码实践、遵守功能原则和强大的透析器使用文化也会有很大帮助）

所以。。。“正确性”。。。尽可能在函数上证明这一点。这是一件好事，为什么我们有合适的工具和快速检查。作为一套通用的指导原则，请尽量写：


尽可能多地使用纯功能。让副作用代码尽可能地与只进行计算和返回值的纯代码隔离

可证明可崩溃的进程。使每一行上都有一个
=
。这就是为什么Erlang的
=
集赋值、断言和统一于一体
具有可证明状态的协议。例如，在没有死锁风险的情况下，无法使两个相同的进程以阻塞方式相互调用。这是并发系统的一个基本限制。CAP定理是另一个。根据这些约束设计系统（这是一种奇怪的解放），并有意识地选择权衡

除非你是在学术界，否则以比函数更大的规模进行校对是一件愚蠢的差事（该函数可能会调用一个巨大的底层世界，所以这并不是一个很大的限制）。为不可能或锁定的条件验证协议也是可能的，如果你有时间，那么就去做吧（否则，像我们这些凡人一样，坚持超时并重新编写过去在调用时实际超时的代码——这不应该经常发生）

所有这些都表明。。。Steve-O几乎肯定会被数据中心的数据电缆绊倒，并在未来两年内拆分集群的次数比任何人都可能看到的要多