разница между обработчиками error_logger и error_logger_tty_h

Я знаю оба error_logger и error_logger_tty_h можно поменять местами. обработчики gen_event error_logger.

Из их исходного кода я знаю, что error_logger сообщения отчетов заканчиваются на erlang:display, а error_logger_tty_h завершается `io:format(user, String, Args)

Что меня смущает, так это то, какая разница между error_logger и error_logger_tty_h для целей?


person keroro520    schedule 27.11.2017    source источник


Ответы (1)


В основном это задокументировано в 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