В основном это задокументировано в http://erlang.org/doc/man/error_logger.html, но в основном модуль error_logger реализует API для запуска и взаимодействия с сервером gen_event или «менеджером событий», который также называется error_logger. Этот процесс будет получать события и передавать их зарегистрированным обработчикам. Модуль API включает такие функции, как error_msg(...) для отправки фактических сообщений о событиях в правильном формате, ожидаемом сервером.
Однако — модуль error_logger также реализует функции обратного вызова gen_event, чтобы его можно было зарегистрировать в качестве обработчика для сервера. Этот код можно было (и, возможно, следовало) поместить в отдельный модуль, но преимущество в том, что тривиально известно, что код обратного вызова уже загружен при запуске логгера ошибок.
Регистратор ошибок запускается сценарием загрузки Erlang до запуска любого приложения, включая приложение ядра. На тот момент о возможностях системы было известно очень мало, но базовое логирование ошибок еще должно работать. Обратные вызовы в модуле error_logger реализуют примитивное ведение журнала, которое выводит любые ошибки на этом раннем этапе прямо на стандартный вывод процесса выполнения Beam, который может быть просто на консоль или /dev/null. Он также буферизует до фиксированного количества сообщений, которые позже будут переданы лучшему обработчику.
Когда приложение ядра запускается, оно считывает настройки среды приложения ядра и заменяет обработчик error_logger на тип, который действительно нужен для системы, например error_logger_tty_h или error_logger_file_h. Он также получит любые буферизованные сообщения от старого регистратора, когда он вступит во владение, чтобы он мог правильно их обрабатывать.
Однако это еще не конец истории, потому что модуль error_logger по-прежнему будет зарегистрирован как обработчик для менеджера событий. В этой новой роли он не выполняет никакой печати или буферизации, но отвечает за пересылку любых событий узлу Erlang, соответствующему процессу-лидеру группы процесса, отправившего событие. Это гарантирует, что события регистратора ошибок всегда возвращаются «домой» и регистрируются на узле процесса-лидера группы.
person
RichardC
schedule
27.11.2017