首页 文章

何时使用erlang应用程序:start或included_applications和主管?

提问于
浏览
4

我有一个Erlang应用程序,它在另一个应用程序的deps目录中有一个依赖项 .

从我的理解,我也可以;

a)通过调用application:start(some_other_app)从我的包含应用程序启动我的依赖应用程序,启动应用程序并显示它在Observer中独立运行 .

b)在我的.app文件中包含我的依赖应用程序{included_applications,[some_other_app]},以便加载应用程序并且不启动,然后从我自己的顶级主管启动包含的应用程序 . 这将再次启动包含的应用程序,并在Observer中显示其在我自己的监督层次结构下运行 .

我的问题是我应该何时使用这两种方法?如果我使用选项“a”并且我的依赖应用程序退出将重新启动,或者我应该使用方法“b”,以便相应地监视我拥有的任何依赖项?

在旁注中我使用Rebar打包和管理我的依赖项 .

谢谢,

安迪 .

3 回答

  • 4

    在应用程序描述符中声明依赖项是可行的方法,因此在大多数方案中应使用选项B.

    应用程序控制器将确保在启动应用程序之前存在并启动所有依赖项(按顺序),如果这些依赖项以错误终止,也会使应用程序失败 . 此外,应用程序控制器将在需要时关闭所有内容 .

    除此之外,如果选择选项A,当使用application:start / 1启动应用程序时,默认情况下将获得临时应用程序,因此您应该使用application:start / 2,将permanent atom作为第二个参数传递 .

    编辑:在应用程序描述符中包含依赖项也有助于提高可见性,在不扫描源代码的情况下很容易知道您的deps .

  • 0

    你可能不应该做a)或b)

    来自Learn You Some Erlang

    看看这一章:Included Applications

    越来越多的人建议不要使用包含的应用程序,原因很简单:它们严重限制了代码重用 . 这样想吧 . 我们花了很多时间研究ppool的体系结构,以便任何人都可以使用它,获得自己的池并随意使用它做任何他们想做的事情 . 如果我们将它推入一个包含的应用程序,那么它就不能再被包含在这个VM上的任何其他应用程序中,并且如果erlcount消失,那么ppool将被删除,破坏了任何需要的第三方应用程序的工作使用ppool . 由于这些原因,包含的应用程序通常被排除在许多Erlang程序员的工具箱之外 . 正如我们将在下一章中看到的那样,版本基本上可以帮助我们以更通用的方式执行相同(以及更多) .

    Release is the Word一章中,您可以阅读有关如何将多个应用程序捆绑到一个版本以及它们如何启动的内容 .

  • 1

    我有一个类似的问题,如何在erlang项目中包含依赖项,然后如何发布它们?

    我得到了各种朋友和erlang邮件列表的帮助......在重新阅读了一些文档和更多的试错之后......我想出了一些东西 . 这很长,所以看看要点:

    https://gist.github.com/3728780

    -Todd

相关问题