JP2017532703A - コンピュータプロセスに関するロギング情報を生成するための高性能機構 - Google Patents

Abstract

本発明は、情報処理装置の組において少なくとも１つのアプリケーションスレッド（Ｆ１、Ｆ２）と少なくとも１つのロギングスレッド（Ｆｊ）とを含むプロセス（Ｐ１）を実行するステップと、少なくとも１つのアプリケーションスレッド内にロギングイベントを検出し、第１のロギング情報をロギングスレッド（Ｆｊ）に直ちに送信するステップと、第１のロギング情報を受信し、第１のロギング情報に基づいて第２のロギング情報を作成するステップと、ロギングスレッドに先に登録された少なくとも１つの処理要素（Ｆｓ、Ｐｊ）に発行インターフェイス（Ｉｐ）を介して第２のロギング情報を発行するステップとを備える、ロギング方法に関する。

Description

発明の分野
本発明は、情報処理装置のアセンブリ上で実行されるソフトウェアアプリケーション内のプロセスロギングの分野に関する。より詳細には、本発明は、いくつかのプロセスおよび/またはスレッドで動作するソフトウェアアプリケーションの場合にプロセスロギングを可能にする方法に関する。

発明の背景
「ロギング」は、ソフトウェアアプリケーションを担当する技術チームの開発者、試験者、または他のメンバーの注意を喚起するために、ソフトウェアアプリケーションの実行中に情報をエクスポートできるようにする機構である。この情報は、特定の誤動作を検出すること、または後者が知られると、それらの原因と判断し、それらの訂正を容易にすることを可能にする。ロギング情報のエクスポートは、ソフトウェアアプリケーションの開発段階中に実行することも、試験者のコミュニティ内の試験段階で実行することもできるが、製造段階で実行することもできる。ロギング情報は、次いで、アプリケーションのユーザにエクスポートされるが、ソフトウェアを担当する技術チームに何らかの方法で「報告され」てもよい。

ロギング情報は、表示端末またはメモリ、特に大容量メモリ「ハードディスク」タイプにエクスポートされてもよい。

特定の「重要な」ソフトウェアアプリケーションでは、応答時間が非常に制限されているが、大量の計算が必要である。これらの２つの要求を調和させるために、それらは従来、情報処理装置のアセンブリからなるシステム上で展開されている。次いで、これらの処理装置を利用するために、並列プログラミング技術が用いられる。

しかしながら、この並列性（膨大である可能性がある）にもかかわらず、応答時間と非常に大量の計算の処理とを両立することは、深刻な制約である。

さらに、ロギングは、例として、表示端末またはメモリに対する入力／出力を必要とする。入力/出力機構は処理時間の点でコストがかかる。結果として、ロギングはソフトウェアアプリケーションの性能上に影響を及ぼす。

重要なソフトウェアアプリケーションの枠組では、その性能を低下させないためにロギングを行わないことが非常に頻繁に選択される。この結果、このソフトウェアアプリケーションの誤動作の検出および修正が困難になる。

発明の概要
本発明の目的は、重要なソフトウェアアプリケーション、特に並列ソフトウェアアプリケーションを含む、効率的なロギングを可能にする機構を提供することによって先行技術を改善することである。

この目的のため、本発明は、
−情報処理装置のアセンブリにわたって少なくとも１つのアプリケーションスレッドと少なくとも１つのロギングスレッドとを含むプロセスを実行することと、
−少なくとも１つのアプリケーションスレッド内にロギングイベントを検出し、第１のロギング情報を前記少なくとも１つのロギングスレッドに直ちに送信することと、
−前記第１のロギング情報を受信し、前記第１のロギング情報から開始する第２のロギング情報を生成することと、
−前記少なくとも１つのロギングスレッドに先に登録された少なくとも１つの処理要素に発行インターフェイスを介して前記第２のロギング情報を発行することとを備える、ロギング方法を提供する。

好ましい実施の形態によれば、本発明は以下の特徴の１つ以上を備え、それらは、別々に、または互いとの部分的もしくは全体的な組合せにおいて用いられてもよく、
−前記少なくとも１つの処理要素は、前記プロセスに属する出力スレッドを含む。

−前記少なくとも１つの処理要素は、前記プロセスとは異なるロギングプロセスのスレッドを含む。

−前記アプリケーションスレッドは、前記第１の情報を、前記少なくとも１つのロギングスレッドに、非同期的に、通信インターフェイスを介して送信する。

−前記通信インターフェイスおよび前記発行インターフェイスはソケットタイプであり、ＺｅｒｏＭＱライブラリに従う。

−前記プロセスの開始において、前記少なくとも１つのアプリケーションスレッドは、その実行を続ける前に、前記少なくとも１つのロギングスレッドの初期設定に対して待機し、前記ロギングスレッドは、それ自体を前記少なくとも１つの処理要素のサブセットと同期させることによって、それ自体を初期化する。

−前記第１のロギング情報は名称およびレベルを含む。
−前記プロセスが複製されると、前記少なくとも１つのロギングスレッドは終了され、次いで、最初の親プロセス内で再起動される。

−前記少なくとも１つのロギングスレッドは、信号を受信すると、前記信号に関連付けられる第２のロギング情報を発行し、次いで、前記信号に関連付けられる処理コードをトリガする。

−前記アプリケーションスレッドは、信号を受信すると、前記信号に関連付けられる第１のロギング情報を前記少なくとも１つのロギングスレッドに送信し、所与の時間待機した後、前記プロセスを終了させる。

本発明の他の特徴および利点は、例として与えられた本発明の好ましい１つの実施の形態の以下の記載を、添付された図面を参照して読むことで明らかになる。

本発明の１つの例示的な実施の形態を概略的に示す。 本発明の１つの実施の形態に従う有限状態機械を概略的に示す。

本発明の詳細な記載
ソフトウェアの観点からは、ソフトウェアアプリケーションは１つ以上のプロセスからなる。

「プロセス」は、情報処理システム（またはコンピュータ）によって実行されているプログラムとして見なされてもよい。プロセスは以下を備えるとして定義されてもよい：
−リードオンリメモリにあってもよいが、最も頻繁には大容量メモリからランダムアクセスメモリにダウンロードされる、実行されるべき命令のセット；
−スタック、作業データなどを保存するためのランダムアクセスメモリ内のアドレス指定空間；
−ネットワークポートなどのようなリソース。

同じプロセスはいくつかのスレッド（またはタスクまたは軽いプロセス）を備えてもよい。プロセスとは対照的に、スレッドは独自の仮想メモリを破棄せず、同じプロセスのすべてのスレッドとそれを共有する。

図１によって示された例では、アプリケーションは２つのプロセスＰ_１、Ｐ_２を備える。プロセスＰ_１は３つのスレッドＦ_１、Ｆ_２、Ｆ_３を備える。図示されないが、プロセスＰ_２もいくつかのスレッドを備えてもよい。

スレッドは、プロセスの寿命、およびより強い理由で、アプリケーションの実行時間とは異なる寿命を有してもよいことが注目され：スレッドは、プロセスの実行中に動的に実行され、スレッドが提供されたタスクが終わると、いつでも終了されてもよい。したがって、図１はソフトウェアアプリケーションの実行における所与の瞬間での状況を示す。

以下では、スレッドＦ_１、Ｆ_２は、それらをロギングスレッドまたはＦ_ｊ、および以下に記載される出力スレッドＦ_ｓから区別するために、「アプリケーションスレッド」と呼ばれる。

ソフトウェアアプリケーションが実行されることを可能にする情報処理システムは、典型的には情報処理装置のアセンブリから形成された並列システムである。

各情報処理装置はたとえば関連付けられる回路（メモリなど）を伴うマイクロプロセッサであってもよく、そのとき、システムは相互接続されたマイクロプロセッサのアセンブリから形成される。別の例は、システムを形成する単一のマイクロプロセッサのそれであり、物理コアのアセンブリから構成される。そのようなマイクロプロセッサは概して「マルチコア」と呼ばれる。

実現されるアーキテクチャとは無関係に、図１の例のプロセスＰ_１、Ｐ_２、Ｐ_Ｊ、およびそれらが含むスレッドは、並列に実行されてもよい。

プロセスＰ１が起動すると、少なくとも１つのスレッドも起動する。この第１のスレッドは、その後、他のスレッドの実行を開始することができる。これらのスレッドはもちろんアプリケーションスレッドであってもよい（言いかえれば、アプリケーションに属し、アプリケーションの「ロジック」が実現されることを可能にする）が、とりわけロギングスレッドＦ_Ｊであってもよい。

以下では、図１において示されるように、１つのロギングスレッドのみが記載される。しかしながら、特に負荷の分散を可能にするために、いくつかのロギングスレッドを提供することが可能である。

１つの実施の形態によれば、ロギングスレッドが起動されると、それは以下を形成する：
−アプリケーションスレッドＦ_１、Ｆ_２、言いかえれば、メインアプリケーションスレッドからの、およびそれが続いて形成するかもしれない任意の潜在的なスレッドからの第１のロギング情報の受信を可能にする通信インターフェイスＩ_Ｃ；
−第２のロギング情報が処理要素に発行されることを可能にする発行インターフェイスＩ_Ｐ。

ここで、「処理要素」はスレッドおよびプロセスを指す。図１において、後で理解されるように、ロギングプロセスＰ_Ｊおよび出力スレッドＦ_Ｓはロギング情報を受信することができるような処理要素を形成する。

本発明の１つの実施の形態によれば、これらのインターフェイスは「ソケット」タイプである。「ソケット」は、「Ｕｎｉｘ（登録商標）」タイプのオペレーティングシステム上で開発された当業者に周知の通信機構であるが、今日では大多数のオペレーティングシステムの下で存在する。

それらはたとえばＺｅｒｏＭＱに従ってもよい。ＺｅｒｏＭＱは、オペレーティングシステムに依存しないさらなるインフラストラクチャサービスを提供するために基底のオペレーティングシステムとアプリケーションとの間に挿入される「ミドルウェア」タイプのプラットフォームである。CORBA（コモンオブジェクトリクエストブローカーアーキテクチャ）などの並行プラットフォームに関しては、たとえば、ＺｅｒｏＭＱは、優れた使用環境および優れたパフォーマンス特性を提供する。コードはアプリケーションスレッドにとって非常に短いため、処理のオーバーロードがほとんどなく、ＺｅｒｏＭＱライブラリ自体内の処理も非常に高速である。したがって、ＺｅｒｏＭＱは本発明の要件に準拠し、所望のサービスが不利益かもしれないいかなる付加的処理もなしに満たされることを可能にする。

ＺｅｒｏＭＱが提供する機構は、ライブラリを通して、Ｃ言語におけるアプリケーションコードを使用してアクセス可能である。したがって、本発明の機構および利点はＣ言語において開発されたプロセスに関してアクセス可能である。

１つの実施の形態によれば、通信インターフェイスＩ_Ｃは非同期インターフェイスであり：それは、アプリケーションスレッドがロギング情報を送信し、次いでその処理を続けることを、ロギングスレッドＦ_Ｊからの肯定応答を待つことなく可能にする。

ＺｅｒｏＭＱを用いる実現例の枠組では、この通信インターフェイスＩ_Ｃはプッシュ／プル型であってもよい。この場合、起動で、ロギングスレッドは、「プル」タイプのソケットを形成する。アプリケーションスレッドＦ_１、Ｆ_２は、次いで、ロギングスレッドＦ_Ｊの「プル」ソケットに接続された「プッシュ」タイプのソケットを介してロギング情報を送信してもよい。

通信インターフェイスＩ_Ｃを形成する２つのタイプのソケット間において、「ｉｎｐｒｏｃ（インプロセス）」プロトコルなどのようなスレッド間およびプロセス内トランスポートプロトコルが確立されてもよい。このプロトコルは同じプロセス内でスレッド間のメッセージの送信を可能にし：情報は、プロセスと関連付けられるコンテキストに属するメモリによって直接送信される。したがって、この機構はいかなる入力／出力も生成せず、したがって本発明に従う方法の高性能に寄与する。

発行インターフェイスＩ_Ｐは、ロギングスレッドＦ_Ｊ内に形成される「ｐｕｂ（発行）」タイプのソケットを含んでもよい。処理要素（プロセスまたはスレッド）Ｐ_Ｊ、Ｆ_Ｓは、ロギングスレッドＰ_Ｊの「ｐｕｂ」ソケットにサブスクライブするために「ｓｕｂ（）」タイプのソケットを形成することができる。したがって、ＺｅｒｏＭＱによって管理される「発行・サブスクライブ」モデルは、メッセージが、既にサブスクライブされたすべての処理要素に送信されることを可能にする。

本発明の１つの実施の形態によれば、プロセス（Ｐ_１）の開始において、アプリケーションスレッドは、その実行を続ける前に、このロギングスレッド（Ｆ_Ｊ）の初期設定を待つ。

それがロギングスレッドＦ_Ｊの実行を開始すると、プロセスＰ_１の（メイン）スレッドは、ロギング情報を受信しなければならないある数の処理要素を示すことができる。それは、このサブスクライブされた処理要素の数が到達されたとき、ロギングスレッドＦ_Ｊから肯定応答を受信するにすぎないことになる。一旦、肯定応答が受信されると、次いで、スレッドはその実行を続けることができる。

同様に、ロギングスレッドＦ_Ｊは、それを、ロギング情報を受信しなければならない数の処理要素と同期させることによって、初期化される。

この目的のため、ロギングスレッドＦ_Ｊは同期情報を発行することができる。この情報の受信で、それを受信した処理要素は、ロギングスレッドに肯定応答を送信することになる。後者は、受信された肯定応答をカウントし、規定数がいつ到達されるかを容易に判断することができる。

この同期段階では、ロギング情報が失われないことが保証され：実際、ロギングスレッドＦ_Ｊと処理要素との間の接続の確立は、ある時間を取り得る。さらに、処理要素それら自体も初期化のプロセスにあり得る。この時間中において、ロギングスレッドＦ_Ｊがロギング情報を直ちに送信し始めた場合、後者は、受信処理要素によって発行されるロギング情報の送信における肯定応答がないために、失われるであろう。このように肯定応答がないことは、十分な性能特性が達成されることを可能にする。

しかしながら、ある状況では、いかなるロギング情報も失わないことは重要または重大にさえなり得る。

この実現例によれば、したがって、この同期機構によってすべての同期情報の受信を保証しなければならない処理要素の数を特定することができる。

この数の要素は、サブスクライブされた処理要素の組のサブセットを決定し、なぜならば一旦初期化段階が終わると、他の処理要素がロギングスレッドＦ_Ｊの発行にサブスクライブすることが完全に可能であるからである。しかしながら、後者はロギングスレッドＦ_Ｊの第１の発行を逃すかもしれない。

本発明に従うロギング方法は、プロセスＰ_１の実行のためのステップを備える。先に記載されたように、この実行は、少なくとも１つのアプリケーションスレッドＦ_１、および１つのロギングスレッドＦ_Ｊの実行を必要を伴う。Ｃ言語で書かれたプロセスの場合、このアプリケーションスレッドＦ_１は関数のmain()の実行に対応してもよい。

一旦初期化段階が終わると、アプリケーションスレッドはソフトウェアアプリケーションのコードを実行する。

方法は、アプリケーションスレッド内にロギングイベントを検出すること、および第１のロギング情報ｅ１、ｅ２をロギングスレッドＦ_Ｊに直ちに送信することにある。

ロギングイベントの検出はそれ自体公知の技術であり、それは、ある条件が満たされるとロギングイベントをトリガするために「ロガー」をコードに挿入することにある。これらの条件は、非常に単純に、（コードの動作の順序を守るために）コード内の正確なポイントを通過すること、またはそうでなければエラーの状況などであってもよい。

アプリケーションスレッドＦ_１、Ｆ_２によって生成されたこのロギング情報は、それを、ロギングスレッドＦ_Ｊによって発行される第２のロギング情報と区別するために、ここでは「第１のロギング情報」と呼ばれる。

この情報は名称およびレベルのみを含んでもよい。１つの実施の形態によれば、この第１の情報はこの名称およびこのレベルのみを含む。

名称は、アプリケーションコード内でロガーを識別する一続きの文字であってもよい。
レベルは、一般的に、イベントの重大性の度合を識別する整数である。このレベルは先に規定されたリストに属してもよく、それは以下を含んでもよい：
−「重大」：一般に、プロセスの終了に至る重大なエラーを示す。

−「エラー」：通常のエラーを示す。
−「警告」：重要でないエラーを示す。

−「出力」：通常のメッセージ（エラーに関連付けられない）を示す。
−「情報」：アプリケーションの（開発者および試験者だけでなく）ユーザの注意を喚起するメッセージを示す。

−「デバッグ」：アプリケーションの試験者（または「デバッガー」）に向けた、より詳細なメッセージを示す。

−「トレース」：最も詳細なレベルに関連付けられるメッセージを示す。その使用は、明らかにアプリケーションの開発段階のために意図される。

このリストは当然のことながら非網羅的である。多くの他のレベルがアプリケーションの開発者によって規定されてもよい。

本発明の機構によって考慮されるためには、開発者または試験者に対して意図されるすべての出力がこの形式に適合することが重要である。したがって、開発者にとっては、特にＣ言語のprintf（）関数による直接出力を避けることが重要である。それらは、たとえば「出力」レベルと置換されてもよい。

この第１の情報はさらに以下のものを含んでもよい：
−ロギングイベントの発生のタイムスタンプ；
−プロセスＰ_１の識別子；
−実行コンテキストについての他の情報：カーネルのスレッドに対する識別子、ソフトウェアアプリケーション名、ファイル名、アプリケーションコードの行番号、実行中の関数の名称など。

本発明によれば、アプリケーションスレッドは、この第１のロギング情報を通信インターフェイスＩ_Ｃを介してロギングスレッドＦ_Ｊに直ちに送信する。先に理解されたように、このインターフェイスは非同期であり、いかなる肯定応答も必要としない。また、一旦送信が（ロギングスレッドによる受信について心配することなく）実行されると、アプリケーションスレッドＦ_１、Ｆ_２は、直ちにアプリケーション処理を続けることができるような態様で、どのようなロックもインストールされない。

１つの実施の形態によれば、どのような他の処理も、ロギングイベントの検出と第１のロギング情報の生成との間には適用されない。

１つの実施の形態によれば、フォーマット化処理動作のみが適用される。
いずれの場合も、本発明によれば、アプリケーションスレッドは入力/出力機構を設定せず：これらの機構はロギングスレッドＦ_Ｊによって実現され、したがってアプリケーションスレッドＦ_１、Ｆ_２の外部に転送される。

その結果、アプリケーションスレッドについて、追加費用は最小限に減じられる。
本発明の１つの実施の形態によれば、アプリケーションコードはモジュールに分割される。各モジュールは名称または識別子と関連付けられ、それはロガーの名称に組入れられてもよい。

たとえば、モジュール「Module1」では、ロガーの名称は、「Module1.logger1」、「Module1.logger2」などである。

この機構は、さまざまなロギングイベントがより明瞭に名付けられることを可能にし：チェーンの終わりで、イベントが発生したコード内の位置は、したがって、その名称に含まれるモジュール名の関数として直接的に決定されてもよい。

ロギングスレッドＦ_Ｊは、アプリケーションスレッドＦ_１、Ｆ_２によって生成された第１のロギング情報を非同期態様で受信する。そのとき、その役割は、アプリケーションスレッドから受信された第１のロギング情報およびおそらくは相補的な情報から開始する第２のロギング情報を生成することである。この相補的な情報は、プロセスのアプリケーションスレッドのすべてに共通の情報であってもよい。

ロギングスレッドＦ_Ｊによって実現される処理は、この第２のロギング情報の生成に制限されてもよい。生成は、一方では、潜在的な相補的情報の追加を含んでもよいが、処理要素によるその利用を可能にする所定のフォーマットに従って、条件付けも含むことができる。

このフォーマット化は、非常に単純であってもよく、第２の情報が、用いられるコンピュータプログラミング言語から独立したフォーマットにあるように、もっぱらあるフォーマット化からなってもよい。

この第２の情報は、その後発行インターフェイスＩ_Ｐを介してロギングスレッドＦ_Ｊによって発行される。次いで、それは、先に記載されたように、ロギングスレッドに既に登録されている１つ以上の処理要素Ｆ_ｓ、Ｐ_Ｊ）によって受信されることができる。

これらの処理要素は、プロセスＰ１に属する出力スレッドＦ_ｓを含んでもよい。この出力スレッドは、表示端末（画面等）上、メモリ、特に大容量メモリなどに保存されたファイル内、などに、第２のロギング情報の出力を形成するよう設計されてもよい。

これらの出力機構は、ハードウェアとの必要とされる対話のため、および一般に肯定応答の必要性（スレッドは、情報が実際にハードディスクなどに保存されたことを確認する必要がある）のため、処理時間において高くつく。

本発明により、これらの機構は、ロギングスレッドの動作シーケンスと並行する態様でその動作シーケンスに従うアプリケーションスレッドに影響を与えない。

処理要素は、さらに、前記プロセス（Ｐ_１）とは異なるロギングプロセス（Ｐ_Ｊ）を含んでもよい。

このプロセスは、さらに、出力スレッドＦ_Ｓと同じ態様で出力機構を実現してもよい。
さらに、それは、ロギング情報の利用のためのより複雑な機構：フィルタ処理などを実現してもよい。

本発明の１つの実施の形態によれば、プロセスＰ_１が複製されると、ロギングスレッドＦ_Ｊおよび潜在的な出力スレッドＦ_Ｓは終了され、次いで、最初の親プロセスＰ_１内で再起動される。娘プロセス内において、これらの２つのスレッドは再起動されない（以下に記載されるように、それらは「ファイナライズ済み」状態に入る）。実際、非常に頻繁に、娘プロセスは、娘プロセスの内容を新しいプログラムによって置き換えて「潰す」関数「exec（）」の実行をトリガし：したがって、ロギングスレッドおよび出力スレッドの自動再起動をトリガする必要はなく、それは逆効果でさえあるかもしれない。

複製はまたは「fork」は、「Ｕｎｉｘ（登録商標）」タイプのオペレーティングシステムで動作するソフトウェアアプリケーションまたはＰｏｓｉｘ規格に準拠したソフトウェアアプリケーションで新しいプロセスを作成するための機構である。

いくつかのスレッドを含むプロセス（「マルチスレッドプロセス」）の複製は重大な問題を提起する。この問題は、特にＰｏｓｉｘ規格、ＩＥＥＥ１００３．１、特に「Rationales」の部分に記載されている。

本発明によって実現される機構は、それが回避されることを可能にする。
さらに、複製「fork（）」を最良に管理するために、状態機械の管理を設定してもよい。

図２は、ロギングスレッドＦ_Ｊのそのような状態機械を示す。スレッドＦ_Ｊは５つの主な状態であり得ることが考えられる。これらの状態は従来、
−「未設定」：「開始されていない」状態に対応し、これは、スレッドが、アプリケーションスレッドがその初期化をトリガする前であってもよい状態に対応する。

−「初期化中」：スレッドの初期化状態に対応し、その間に前述の同期化ステップが特に行われる。

−「初期化済」：ロギングスレッドの通常動作に対応する。
−「ファイナライズ中」：ロギングスレッドの終了に対応する。

−「ファイナライズ済み」：スレッドが終わった状態に対応する。
ある状態では、本発明のこの実施の形態によれば、複製は禁じられる。これは、「初期化中」状態および「ファイナライズ中」状態に対する場合であり：矢印「fork（）」は「不正な」状態に至る。

特定の状態「未設定」および「ファイナライズ済み」では、複製が許可されてもよく、特定の処理動作を発生させなくてもよい。矢印「fork（）」は現在の状態にループして戻る。

「初期化済」状態では、複製は、ロギングスレッドを終了させるために遷移を状態「ファイナライズ中」に移行する。

潜在的な出力スレッドＦ_Ｓについて同じことが言える。
一旦スレッドが終わると、プロセスを複製することができる。

一旦、複製が実行されると、スレッドＦ_ＪおよびＦ_Ｓは再起動されてもよい。親プロセス（言いかえれば初期プロセスＰ_１）では、スレッドは、それらが複製前であった状態、言いかえれば「初期化済」状態で再起動される。娘プロセスでは、スレッドは「未設定」状態で開始し：次いで、娘プロセスのアプリケーションスレッドはそれに状態を変更させるためにその初期設定を起動しなければならない。

さらに、ＰｏｓｉｘまたはＵｎｉｘ（登録商標）タイプのシステムの下で動作するプロセスＰ_１は、信号を受信することができる。これらの信号は、信号ＳＩＧＩＮＴ、ＳＩＧＴＥＲＭ、ＳＩＧＱＵＩＴ、ＳＩＧＳＥＧＶ、ＳＩＧＢＵＳなどのような、プロセスを終了させるために与えられてもよい。

このような信号がロギングスレッドＦ_Ｊによって受信されると、後者はそれらをそれらの性質に応じて処理するかどうかを選択してもよい。たとえば、信号ＳＩＧＩＮＴ、ＳＩＧＴＥＲＭおよびＳＩＧＱＵＩＴは、アプリケーションスレッドによって処理される必要があると考慮されてもよく、したがって、ロギングスレッドによって考慮されなくてもよい。それは、他方、ＳＩＧＳＥＧＶおよびＳＩＧＢＵＳなどの他のタイプの信号を考慮してもよい。

そのような信号の受信と同時に、ロギングスレッドＦ_Ｊは、これはロギングイベントを構成すると考慮し、次いで、この信号と関連付けて、ロギング情報を発行してもよい。

続いて、それはもう一度この信号およびその「通常の」処理をトリガしてもよい。信号の通常の処理は、典型的には「ハンドラ」と呼ばれ、この信号と関連付けられる処理コードによって提供される。この信号ＳＩＧＳＥＧＶまたはＳＩＧＢＵＳの通常の処理はプロセスの終了に至る。

したがって、この機構によって、プロセスは、終わることにある、期待される挙動を採用するが、このイベントの受信にリンクされるロギングも確実に行われ：さらに、処理要素がロギングスレッドにサブスクライブされる場合には、それにプロセスＰ_１の終了の原因が通知される。

信号がアプリケーションスレッドによって受信される場合には、後者はそれがロギングイベントを構成すると判断してもよい。この目的のため、ある特定のコードが「ハンドラ」として信号に関連付けられてもよく：所与の信号の受信で、この特定のコードがオペレーティングシステムによってトリガされる。

この特定のコードは通信インターフェイスＩ_Ｃを介してロギングスレッドに（第１の）ロギング情報の即時送信を可能にする。

このコードは、さらにロギングスレッドがこの第１のロギング情報から開始する第２のロギング情報を生成し、発行インターフェイスを介してそれを発行することを可能にする待ち時間を含んでもよい。

そのときのみ、特定のコードは、プロセスの終了を実現するかまたはプロセスそれ自体を終了するために、通常の処理コードを呼出すことができる。

したがって、サブスクライブされた処理要素は、プロセスの終了の原因を通知されることができる。

言うまでもなく、本発明は、説明され図示された例および実施の形態に限定されず、当業者がアクセス可能な多数の変形例が可能である。

Claims (10)

1. ロギング方法であって、
   情報処理装置のアセンブリにわたって少なくとも１つのアプリケーションスレッド（Ｆ_１、Ｆ_２）と少なくとも１つのロギングスレッド（Ｆ_ｊ）とを含むプロセス（Ｐ_１）を実行することと、
   前記少なくとも１つのアプリケーションスレッド内にロギングイベントを検出し、第１のロギング情報を前記少なくとも１つのロギングスレッド（Ｆ_Ｊ）に直ちに送信することと、
   前記第１のロギング情報を受信し、前記第１のロギング情報から開始する第２のロギング情報を生成することと、
   前記少なくとも１つのロギングスレッドに先に登録された少なくとも１つの処理要素（Ｆ_ｓ、Ｐ_Ｊ）に発行インターフェイス（Ｉ_Ｐ）を介して前記第２のロギング情報を発行することとを備える、ロギング方法。
2. 前記少なくとも１つの処理要素は、前記プロセス（Ｐ_１）に属する出力スレッド（Ｆ_ｓ）を含む、請求項１に記載の方法。
3. 前記少なくとも１つの処理要素は、前記プロセス（Ｐ_１）とは異なるロギングプロセス（Ｐ_Ｊ）のスレッドを含む、請求項１または２に記載の方法。
4. 前記アプリケーションスレッド（Ｆ_１）は、前記第１の情報を、前記少なくとも１つのロギングスレッドに、非同期態様で、通信インターフェイス（Ｉ_Ｃ）を介して送信する、先行する請求項の１つに記載の方法。
5. 前記通信インターフェイスおよび前記発行インターフェイスはソケットタイプであり、ＺｅｒｏＭＱライブラリに従う、先行する請求項の１つに記載の方法。
6. 前記プロセス（Ｐ_１）の開始において、前記少なくとも１つのアプリケーションスレッド（Ｆ_１、Ｆ_２）は、その実行を続ける前に、前記少なくとも１つのロギングスレッド（Ｆ_ｊ）の初期設定に対して待機し、前記ロギングスレッドは、それ自体を前記少なくとも１つの処理要素（Ｆ_ｓ、Ｐ_Ｊ）のサブセットと同期させることによって初期化される、先行する請求項の１つに記載の方法。
7. 前記第１のロギング情報は名称およびレベルを含む、先行する請求項の１つに記載の方法。
8. 前記プロセス（Ｐ_１）が複製されると、前記少なくとも１つのロギングスレッド（Ｆ_Ｊ）は終了され、次いで、最初の親プロセス（Ｐ_１）内で再起動される、先行する請求項の１つに記載の方法。
9. 前記少なくとも１つのロギングスレッドは、信号を受信すると、前記信号に関連付けられる第２のロギング情報を発行し、次いで、前記信号に関連付けられる処理コードをトリガする、先行する請求項の１つに記載の方法。
10. 前記アプリケーションスレッドは、信号を受信すると、前記信号に関連付けられる第１のロギング情報を前記少なくとも１つのロギングスレッドに送信し、所与の時間待機した後、前記プロセスを終了させる、先行する請求項の１つに記載の方法。