Приложение Simple_one_for_one

#erlang #erlang-supervisor #simple-one-for-one

#erlang #erlang-супервизор #простой-один к одному

Вопрос:

У меня есть супервизор, который запускает дочерние элементы simple_one_for_one. Каждый дочерний элемент фактически является супервизором, у которого есть свое собственное дерево. Каждый дочерний элемент запускается с уникальным идентификатором, поэтому я могу их различать. Затем каждый gen_server запускается с помощью start_link(Id), где:

 -define(SERVER(Id), {global, {Id, ?MODULE}}).
start_link(Id) ->
    gen_server:start_link(?SERVER(Id), ?MODULE, [Id], []).
  

Таким образом, каждый gen_server может быть легко адресован с помощью {global, {Id, module_name}}.

Теперь я хотел бы включить этот дочерний супервизор в приложение. Итак, мой материнский супервизор должен запускать приложения вместо супервизоров. Это должно быть просто, за исключением одной части: передачи идентификатора приложению. Запустить супервизор с идентификатором просто: supervisor:start_child(?СЕРВЕР, [Id]). Как мне это сделать для приложения? Как я могу запустить несколько приложений с одинаковым именем (чтобы я мог получить доступ к одному и тому же файлу .app) с разными идентификаторами (чтобы я мог запускать своих дочерних приложений с помощью supervisor:start_child(?SERVER, [Id]))?

Если мой вопрос недостаточно ясен, вот мой код. Итак, в данный момент es_simulator_dispatcher запускает es_simulator_sup. Я хотел бы иметь это: es_simulator_dispatcher запускает es_simulator_app, который запускает es_simulator_sup. Вот и все, что от него требуется 🙂

Заранее спасибо, dijxtra

Ответ №1:

Приложения не запускаются ни под чем другим, они являются абстракцией верхнего уровня. При запуске приложения с помощью application:start/1 приложение запускается контроллером приложений, который управляет приложениями. Приложения содержат код и данные и, возможно, во время выполнения дерево контроля процессов, выполняющих работу приложений во время выполнения. Выполнение нескольких вызовов приложения на самом деле не имеет смысла из-за природы приложений.

Я бы посоветовал прочитать Руководство пользователя по принципам проектирования OTP для описания компонентов OTP, их взаимосвязи и как они предназначены для использования.

Комментарии:

1. Да, вы правы … кажется, что в Erlang невозможно сделать то, что я хочу сделать. Жаль.

Ответ №2:

Я не думаю, что приложения предназначены для динамического построения, как вы хотите. Я бы создал одно приложение, потому что в Erlang приложения представляют собой скорее пакеты кода, чем пакеты запущенных процессов (можно сказать, что они являются артефактом времени компиляции в большей степени, чем времени выполнения).

Обычно вы передаете конфигурацию приложению через встроенную систему настройки. То есть вы используете application:get_env(Key) для чтения чего-то, что оно должно использовать. Также существует application:set_env(...) возможность поместить определенную конфигурацию в одно приложение, но предпочтительным способом является файл конфигурации на диске. Это может сработать, а может и не сработать в вашем случае.

В некотором смысле то, что вы делаете, соответствует созданию 200 файлов конфигурации Apache, а затем запуску 200 систем Apache рядом друг с другом, вместо того, чтобы запускать одну, а затем обрабатывать несколько доменов внутри нее.