主管：

Question

我有一个名为“monitor_node”的进程层次结构。每个monitor_nodes都由一位主管监督。

现在，这些节点中的每一个都可能具有复杂的内部结构。意思是，它可能（或可能不）具有一些正常运行所需的子过程。示例：处理发送保持活动消息。到目前为止，我一直在使用普通的spawn_link来创建这些“内部” 过程

但是，我已经意识到在monitor_node（正在监督）的init函数中生成它们有时会导致此函数失败（因此整个管理程序树失败）。我的问题是：将这些内部流程附加到主管树是否是一个很好的解决方案？我正在考虑将monitor_node更改为监督其内部流程的主管。

我的怀疑是：

我必须监督相当多的非常小的进程。我不确定这是不是一个好习惯。
我可能事先并不知道“内部”流程是一个简单的流程，或者有一些内部结构（也会产生其他流程）。如果后者是这种情况，那么我可能应该将这些“内部 - 内部”进程附加到主管树。

我希望我没有太多困惑你。期待着回答。

编辑：

一个非常相似（如果不是相同）的问题是讨论here（第3篇文章）。给出的解决方案与我给CRAP ANSWERS给出的解决方案几乎相同。

Answer 1

这里有一个技巧，包括使用两个主管。你的树就像：

main_sup -> worker
main_sup -> attached_pool_sup

attached_pool_sup -> workers

主要是one_for_all，所以如果工作人员或游泳池主管死亡，那么树就完成了并且被杀掉了。游泳池主管是simple_one_for_one，适合拥有数百或数千名工人。

初始化：

不要在init回调中做太多工作。主管将等待初始化完成，并且如果花费的时间超过正常时间，您可以设置超时（在您的情况下可以增加）。

一个技巧是快速超时（从init返回0超时）然后在handle_info超时回调中处理其他设置。这样你就不会阻止主管。小心这里的比赛！