Какой смысл иметь временных детей для руководителей Erlang?
Супервизоры предназначены для перезапуска процессов, которые не работают. Временные процессы - это те, которые никогда не следует перезапускать. Итак, зачем беспокоиться о том, чтобы этот тип ребенка был у руководителя? Это в основном так, что они могут быть прекращены как часть стратегии one_for_all, или когда приложение закрыто?
2 ответа
Есть несколько проблем с тем, что супервизоры существуют только для перезапуска заданий. Вот несколько из них:
- Значение слова "временный" расплывчато.
- Перезапуск задания, которое где-то не выполнено по неизвестной (возможно, связанной с ресурсами или иным образом внешней) причине, и разрешение истечения процесса, завершившегося с заданием, - это две разные вещи.
- Супервизоры предоставляют согласованный интерфейс или дверной проем не только для перезапусков, но и для запуска, регистрации, трассировки, очистки после сбоев, обслуживания состояния на более высоком (как в "менее приемлемом для сбоя") уровне и различных других встроенных функций OTP, которые созданы в инструменты, такие как SASL.
В конечном итоге все процессы носят временный характер. Чтобы смоделировать это в системе Erlang, вы должны сделать так, чтобы супервизор порождал и давал возможность истечь определенным заданиям. Вот почему вы можете добавлять задания к супервизору, иметь различные типы супервизоров, и частый ответ на вопрос "как найти процесс X" - "спросить своего супервизора" (хотя шаблон менеджера также является распространенным и включает в себя еще больше супервизоров).).
Конечно, вы можете просто запустить какой-то случайный одноразовый процесс в середине вашего кода, чтобы завершить какую-то одноразовую задачу (а иногда это правильно), но теперь вам нужно написать код обработки сбоев внутри вашего процесса. на случай, если что-то не получится (если вы заботитесь о работе, то есть - а если нет, то почему вы это делаете?). Если вы будете делать это очень часто, вы в конечном итоге напишите неформально заданную, ошибочную реализацию многих функций, которые уже являются частью того, что OTP предоставляет в виде супервизоров - это версия Erlang для Десятого правила Гринспуна.
(Десятое правило происходит постоянно, потому что, хотя язык Erlang очень маленький, простой и не подвержен многочисленным заблуждениям в хакерстве; OTP и среда выполнения огромны, сложны, а часть Erlang/OTP, являющаяся предметом неправильные представления стороннего наблюдателя.)
Большинство модулей времени, написанных для выполнения разовой работы, пишутся с start/0,N (или же do или что-то в этом роде), которая на самом деле вызывает именованного супервизора, добавляет временного работника в свой список и запускает его под надзор, даже если он временный. Это не правильно делать в каждом случае, но это довольно распространенная вещь, и я склоняюсь к тому, чтобы сделать что-то подобное, пока у меня не будет причины не делать этого.
Думать об этом по-другому... В реальном мире этот термин "руководитель" означает контролировать работу, задачу или работника. Он не такой широкий, как "менеджер", но гораздо шире, чем просто "нанимать новых работников, когда уходит один работник" - это даже слишком узкое определение для отдела кадров.
Роль супервизора заключается не только в том, чтобы запускать / перезапускать процессы, но также и уничтожать их.
Обязательно нужно позаботиться о процессах уничтожения, потому что при длительном применении существует риск накопления "лишенных" процессов, которые стали бесполезными. Таким образом, как правило, каждый процесс должен быть связан с некоторыми другими, если не гарантировано, что он умрет сам в течение ограниченного времени.
Это может быть сделано в самом модуле, и имеет смысл, когда, например, процесс A порождает процесс B и когда они должны всегда умирать в одинаковых условиях (не забывайте, что процесс, умирающий по причине "нормальной", будет не распространяет свою смерть на связанные процессы). Но это имеет два основных неудобства:
- Поскольку ситуация часто намного сложнее, он добавляет некоторый (много?) Код управления процессами в ваш модуль в сочетании с его основным кодом, снижая читабельность приложения.
- это даст вам очень частичное (локальное) представление об управлении процессами, в то время как это является сквозной и архитектурной проблемой. Опять же, это приводит к плохой читаемости управления процессом.
Использование супервизора, по сути, дерева надзора, позволяет отделить управление процессом от кода вашего приложения. Он обеспечивает комплексное, централизованное и стандартизированное представление о нем, интегрированное в среду OTP.
Временные процессы существуют (в некоторых случаях они составляют большинство); их жизненный цикл должен быть управляемым; это работа руководителей.