私はerror_loggerとerror_logger_tty_hの両方がgen_event error_loggerのスワップ可能ハンドラであることを知っています。そのソースコードからerror_loggerとerror_logger_tty_hハンドラの違い
、私はerlang:displayを終わるerror_loggerレポートメッセージを知っている、とerror_logger_tty_hは`io:format(user, String, Args)
を終わる私が混乱して感じる何が、どのような目的のためにerror_loggerとerror_logger_tty_hの違いは？
これは主にhttp://erlang.org/doc/man/error_logger.htmlに記載されていますが、error_loggerモジュールは、gen_eventサーバーまたは「event manager」（error_loggerという名前）の開始および操作用のAPIを基本的に実装しています。このプロセスはイベントを受け取り、登録されたハンドラに渡します。 APIモジュールには、サーバーが予期している正しい形式で実際のイベントメッセージを送信するためのerror_msg（...）などの関数が含まれています。
- error_loggerモジュールはgen_eventコールバック関数も実装しているため、サーバーのハンドラとして登録することができます。このコードは別のモジュールに置かれている可能性がありますが、おそらくそうでなければなりませんが、エラーロガーが起動したときにコールバックコードが既にロードされていることがよく知られています。
エラーロガーは、カーネルアプリケーションを含むアプリケーションが起動される前に、Erlangブートスクリプトによって起動されます。その時点では、システムの機能についてはほとんど分かっていませんが、基本的なエラーログ機能はまだ動作する必要があります。 error_loggerモジュールのコールバックは、この初期段階のエラーをBeamランタイムプロセスの標準出力に直接出力するプリミティブロギングを実装しています。これは、コンソールまたは/ dev/nullの可能性があります。また、後でより良いハンドラに渡すために一定数のメッセージをバッファリングします。
カーネルアプリケーションが起動すると、カーネルアプリケーションの環境設定が読み込まれ、error_logger_tty_hやerror_logger_file_hなど、実際にシステムに必要な種類にerror_loggerハンドラがスワップされます。また、古いロガーから引き継がれたときにバッファされたメッセージを取得し、適切に処理することができます。
しかし、error_loggerモジュールはまだイベントマネージャのハンドラとして登録されているので、これはかなりストーリーの終わりではありません。この新しいロールでは、印刷やバッファリングは行われませんが、イベントを送信したプロセスのグループリーダープロセスに対応するErlangノードにイベントを転送する役割を果たします。これにより、エラー・ロガー・イベントは常に、自らのグループリーダー・プロセスのノードにログ記録されるようになります。