Какова цель непосредственного руководителя во многих примерах ковбоя

Question

В примерах, представленных на ковбойском github, и в некоторых других примерах, которые я нашел в Интернете, есть один-к-одному супервизор, который, похоже, ничего не делает. Я даже считаю, что видел пример, в котором был следующий комментарий: "Как настоящий супервайзер ничего не делает".

Какова цель модуля supervisor, который, кажется, является частью многих примеров ковбоев?

Из примера echo_get:

%% Feel free to use, reuse and abuse the code in this file.

%% @private-module(echo_get_sup).
-behaviour(supervisor).

%% API.
-export([start_link/0]).

%% supervisor.
-export([init/1]).

%% API.
-spec start_link() -> {ok, pid()}.
 start_link() ->    
     supervisor:start_link({local, ?MODULE}, ?MODULE, []).

%% supervisor.
init([]) ->
    Procs = [], 
    {ok, {{one_for_one, 10, 10}, Procs}}.

Answer 1

Из документации по поведению приложения erlang:

start вызывается при запуске приложения и должен создать дерево контроля, запустив главный супервизор. Ожидается, что вернет pid топ-супервайзера и опциональный термин State, который по умолчанию [], Этот срок передается как есть, чтобы остановиться.

У него есть этот фиктивный руководитель, поэтому он может вызвать его в конце функции запуска здесь. Я думаю, что это не имеет практической цели, кроме как удовлетворить это условие.

Answer 2

Вам не нужно указывать всех детей, которыми руководит руководитель, когда он запускается. Вы можете добавлять / запускать их динамически, используя supervisor:start_child/2 и управлять ими, используя supevisor:restart_child/2, supervisor:terminate_child/2 а также supervisor:delete_child/2, Это означает, что даже если у супервайзера нет детей с самого начала, это не значит, что он просто дурачок.

Комментарий о том, что настоящий супервизор "ничего не делает", скорее всего, связан с тем фактом, что супервизор может только контролировать процессы, а не выполнять какую-либо работу, как рабочие процессы. Или, по крайней мере, это должно означать!