主管在那里重启失败的进程.临时进程是永远不应重新启动的进程.那么,为什么要为主管打扰这种类型的孩子呢?是否主要是因为它们可以作为one_for_all策略的一部分终止,或者当应用程序终止时?
zxq*_*xq9 10
有一些问题,只有主管才能重新启动作业.这里有几个:
最终,所有流程都是暂时的.要在Erlang系统中对此进行建模,您必须使主管可以生成并让某些作业过期.这就是为什么你可以向主管添加工作,拥有各种类型的主管,并且经常回答"我如何找到进程X"是"询问其主管"(尽管经理模式也很常见,涉及更多的主管)).
您当然可以在代码中间生成一些随机的一次性过程来完成一些一次性任务(有时候这是正确的事情),但现在您必须在流程中编写崩溃处理代码以防万一失败(如果你关心这份工作,那就是 - 如果你不关心,你为什么要这样做?).如果你经常这样做,你最终会编写一个非正式指定的,错误的实现许多功能,这些功能已经成为OTP以监督者形式提供的一部分 - 这是Greenspun的第十条规则的Erlang版本.
(第十条规则的事情一直在发生,因为虽然语言 Erlang非常小,简单而且不是hackerdom中许多误解的主题; OTP和运行时环境是巨大的,复杂的,而Erlang/OTP的一部分是一个令人讨厌的局外人误解.)
大多数情况下,为执行某些一次性工作而编写的模块都是用一种start/0,N
(或do
类似的)函数编写的,这种函数实际上调用一个命名的管理程序,在其列表中添加一个临时工作者,并在监督下将其转换为旋转状态.虽然这是暂时的.这在每种情况下都不是正确的事情,但它是一个非常常见的事情 - 我倾向于默认这样的事情,直到我有理由不这样做.
以另一种方式来思考......在现实世界中,这个术语"主管"意味着监督工作,任务或工人.它不像"经理人"那么广泛,但它的范围远远超过"只要一个工人退出就雇用新工人" - 这对于人力资源部门来说甚至太狭隘了.
主管的角色不仅是启动/重新启动流程,而且是杀死它们。
必须强制执行杀死进程,因为在长寿命的应用程序中,存在积累无用的“孤立”进程的风险。因此,根据经验,除非确保在有限的时间内自行死亡,否则每个过程都应与其他过程联系在一起。
这可以在模块本身中完成,当例如进程A产生进程B以及何时它们应始终在相同条件下死掉时,这是有意义的(请不要忘记进程由于“正常”的原因而死亡。不会将其死亡传播到链接的进程)。但这有两个主要的不便之处:
使用主管(实际上是监视树)可以使您将流程管理与应用程序代码分开。它提供了完整,集中和标准化的视图,并集成在OTP环境中。
存在临时过程(在某些情况下为临时过程);他们的生命周期必须得到管理;这是主管的工作。