(57)【特許請求の範囲】
【請求項１】
ロギング方法であって、
情報処理装置のアセンブリにわたって少なくとも１つのアプリケーションスレッド（Ｆ１、Ｆ２）と少なくとも１つのロギングスレッド（Ｆｊ）とを含むプロセス（Ｐ１）を実行することと、
前記少なくとも１つのアプリケーションスレッド内にロギングイベントを検出し、第１のロギング情報を前記少なくとも１つのロギングスレッド（ＦＪ）に直ちに送信することと、
前記第１のロギング情報を受信し、前記第１のロギング情報から開始する第２のロギング情報を生成することと、
前記少なくとも１つのロギングスレッドに先に登録された少なくとも１つの処理要素（Ｆｓ、ＰＪ）に発行インターフェイス（ＩＰ）を介して前記第２のロギング情報を発行することとを備える、ロギング方法。
【請求項２】
前記少なくとも１つの処理要素は、前記プロセス（Ｐ１）に属する出力スレッド（Ｆｓ）を含む、請求項１に記載の方法。
【請求項３】
前記少なくとも１つの処理要素は、前記プロセス（Ｐ１）とは異なるロギングプロセス（ＰＪ）のスレッドを含む、請求項１または２に記載の方法。
【請求項４】
前記アプリケーションスレッド（Ｆ１）は、前記第１のロギング情報を、前記少なくとも１つのロギングスレッドに、非同期態様で、通信インターフェイス（ＩＣ）を介して送信する、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
前記通信インターフェイスおよび前記発行インターフェイスはソケットタイプであり、ＺｅｒｏＭＱライブラリに従う、請求項４に記載の方法。
【請求項６】
前記プロセス（Ｐ１）の開始において、前記少なくとも１つのアプリケーションスレッド（Ｆ１、Ｆ２）は、その実行を続ける前に、前記少なくとも１つのロギングスレッド（Ｆｊ）の初期設定に対して待機し、前記ロギングスレッドは、それ自体を前記少なくとも１つの処理要素（Ｆｓ、ＰＪ）のサブセットと同期させることによって初期化される、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記第１のロギング情報は名称およびレベルを含む、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記プロセス（Ｐ１）が複製されると、前記少なくとも１つのロギングスレッド（ＦＪ）は終了され、次いで、最初の親プロセス（Ｐ１）内で再起動される、請求項１〜７のいずれか１項に記載の方法。
【請求項９】
前記少なくとも１つのロギングスレッドは、信号を受信すると、前記信号に関連付けられる第２のロギング情報を発行し、次いで、前記信号に関連付けられる処理コードをトリガする、請求項１〜８のいずれか１項に記載の方法。
【請求項１０】
前記アプリケーションスレッドは、信号を受信すると、前記信号に関連付けられる第１のロギング情報を前記少なくとも１つのロギングスレッドに送信し、所与の時間待機した後、前記プロセスを終了させる、請求項１〜９のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の分野
本発明は、情報処理装置のアセンブリ上で実行されるソフトウェアアプリケーション内のプロセスロギングの分野に関する。より詳細には、本発明は、いくつかのプロセスおよび/またはスレッドで動作するソフトウェアアプリケーションの場合にプロセスロギングを可能にする方法に関する。
【背景技術】
【０００２】
発明の背景
「ロギング」は、ソフトウェアアプリケーションを担当する技術チームの開発者、試験者、または他のメンバーの注意を喚起するために、ソフトウェアアプリケーションの実行中に情報をエクスポートできるようにする機構である。この情報は、特定の誤動作を検出すること、または後者が知られると、それらの原因と判断し、それらの訂正を容易にすることを可能にする。ロギング情報のエクスポートは、ソフトウェアアプリケーションの開発段階中に実行することも、試験者のコミュニティ内の試験段階で実行することもできるが、製造段階で実行することもできる。ロギング情報は、次いで、アプリケーションのユーザにエクスポートされるが、ソフトウェアを担当する技術チームに何らかの方法で「報告され」てもよい。
【０００３】
ロギング情報は、表示端末またはメモリ、特に大容量メモリ「ハードディスク」タイプにエクスポートされてもよい。
【０００４】
特定の「重要な」ソフトウェアアプリケーションでは、応答時間が非常に制限されているが、大量の計算が必要である。これらの２つの要求を調和させるために、それらは従来、情報処理装置のアセンブリからなるシステム上で展開されている。次いで、これらの処理装置を利用するために、並列プログラミング技術が用いられる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、この並列性（膨大である可能性がある）にもかかわらず、応答時間と非常に大量の計算の処理とを両立することは、深刻な制約である。
【０００６】
さらに、ロギングは、例として、表示端末またはメモリに対する入力／出力を必要とする。入力/出力機構は処理時間の点でコストがかかる。結果として、ロギングはソフトウェアアプリケーションの性能上に影響を及ぼす。
【０００７】
重要なソフトウェアアプリケーションの枠組では、その性能を低下させないためにロギングを行わないことが非常に頻繁に選択される。この結果、このソフトウェアアプリケーションの誤動作の検出および修正が困難になる。
【０００８】
発明の概要
本発明の目的は、重要なソフトウェアアプリケーション、特に並列ソフトウェアアプリケーションを含む、効率的なロギングを可能にする機構を提供することによって先行技術を改善することである。
【課題を解決するための手段】
【０００９】
この目的のため、本発明は、
−情報処理装置のアセンブリにわたって少なくとも１つのアプリケーションスレッドと少なくとも１つのロギングスレッドとを含むプロセスを実行することと、
−少なくとも１つのアプリケーションスレッド内にロギングイベントを検出し、第１のロギング情報を前記少なくとも１つのロギングスレッドに直ちに送信することと、
−前記第１のロギング情報を受信し、前記第１のロギング情報から開始する第２のロギング情報を生成することと、
−前記少なくとも１つのロギングスレッドに先に登録された少なくとも１つの処理要素に発行インターフェイスを介して前記第２のロギング情報を発行することとを備える、ロギング方法を提供する。
【００１０】
好ましい実施の形態によれば、本発明は以下の特徴の１つ以上を備え、それらは、別々に、または互いとの部分的もしくは全体的な組合せにおいて用いられてもよく、
−前記少なくとも１つの処理要素は、前記プロセスに属する出力スレッドを含む。
【００１１】
−前記少なくとも１つの処理要素は、前記プロセスとは異なるロギングプロセスのスレッドを含む。
【００１２】
−前記アプリケーションスレッドは、前記第１の情報を、前記少なくとも１つのロギングスレッドに、非同期的に、通信インターフェイスを介して送信する。
【００１３】
−前記通信インターフェイスおよび前記発行インターフェイスはソケットタイプであり、ＺｅｒｏＭＱライブラリに従う。
【００１４】
−前記プロセスの開始において、前記少なくとも１つのアプリケーションスレッドは、その実行を続ける前に、前記少なくとも１つのロギングスレッドの初期設定に対して待機し、前記ロギングスレッドは、それ自体を前記少なくとも１つの処理要素のサブセットと同期させることによって、それ自体を初期化する。
【００１５】
−前記第１のロギング情報は名称およびレベルを含む。
−前記プロセスが複製されると、前記少なくとも１つのロギングスレッドは終了され、次いで、最初の親プロセス内で再起動される。
【００１６】
−前記少なくとも１つのロギングスレッドは、信号を受信すると、前記信号に関連付けられる第２のロギング情報を発行し、次いで、前記信号に関連付けられる処理コードをトリガする。
【００１７】
−前記アプリケーションスレッドは、信号を受信すると、前記信号に関連付けられる第１のロギング情報を前記少なくとも１つのロギングスレッドに送信し、所与の時間待機した後、前記プロセスを終了させる。
【００１８】
本発明の他の特徴および利点は、例として与えられた本発明の好ましい１つの実施の形態の以下の記載を、添付された図面を参照して読むことで明らかになる。
【図面の簡単な説明】
【００１９】
【図１】本発明の１つの例示的な実施の形態を概略的に示す。
【図２】本発明の１つの実施の形態に従う有限状態機械を概略的に示す。
【発明を実施するための形態】
【００２０】
本発明の詳細な記載
ソフトウェアの観点からは、ソフトウェアアプリケーションは１つ以上のプロセスからなる。
【００２１】
「プロセス」は、情報処理システム（またはコンピュータ）によって実行されているプログラムとして見なされてもよい。プロセスは以下を備えるとして定義されてもよい：
−リードオンリメモリにあってもよいが、最も頻繁には大容量メモリからランダムアクセスメモリにダウンロードされる、実行されるべき命令のセット；
−スタック、作業データなどを保存するためのランダムアクセスメモリ内のアドレス指定空間；
−ネットワークポートなどのようなリソース。
【００２２】
同じプロセスはいくつかのスレッド（またはタスクまたは軽いプロセス）を備えてもよい。プロセスとは対照的に、スレッドは独自の仮想メモリを破棄せず、同じプロセスのすべてのスレッドとそれを共有する。
【００２３】
図１によって示された例では、アプリケーションは２つのプロセスＰ１、Ｐ２を備える。プロセスＰ１は３つのスレッドＦ１、Ｆ２、Ｆ３を備える。図示されないが、プロセスＰ２もいくつかのスレッドを備えてもよい。
【００２４】
スレッドは、プロセスの寿命、およびより強い理由で、アプリケーションの実行時間とは異なる寿命を有してもよいことが注目され：スレッドは、プロセスの実行中に動的に実行され、スレッドが提供されたタスクが終わると、いつでも終了されてもよい。したがって、図１はソフトウェアアプリケーションの実行における所与の瞬間での状況を示す。
【００２５】
以下では、スレッドＦ１、Ｆ２は、それらをロギングスレッドまたはＦｊ、および以下に記載される出力スレッドＦｓから区別するために、「アプリケーションスレッド」と呼ばれる。
【００２６】
ソフトウェアアプリケーションが実行されることを可能にする情報処理システムは、典型的には情報処理装置のアセンブリから形成された並列システムである。
【００２７】
各情報処理装置はたとえば関連付けられる回路（メモリなど）を伴うマイクロプロセッサであってもよく、そのとき、システムは相互接続されたマイクロプロセッサのアセンブリから形成される。別の例は、システムを形成する単一のマイクロプロセッサのそれであり、物理コアのアセンブリから構成される。そのようなマイクロプロセッサは概して「マルチコア」と呼ばれる。
【００２８】
実現されるアーキテクチャとは無関係に、図１の例のプロセスＰ１、Ｐ２、ＰＪ、およびそれらが含むスレッドは、並列に実行されてもよい。
【００２９】
プロセスＰ１が起動すると、少なくとも１つのスレッドも起動する。この第１のスレッドは、その後、他のスレッドの実行を開始することができる。これらのスレッドはもちろんアプリケーションスレッドであってもよい（言いかえれば、アプリケーションに属し、アプリケーションの「ロジック」が実現されることを可能にする）が、とりわけロギングスレッドＦＪであってもよい。
【００３０】
以下では、図１において示されるように、１つのロギングスレッドのみが記載される。しかしながら、特に負荷の分散を可能にするために、いくつかのロギングスレッドを提供することが可能である。
【００３１】
１つの実施の形態によれば、ロギングスレッドが起動されると、それは以下を形成する：
−アプリケーションスレッドＦ１、Ｆ２、言いかえれば、メインアプリケーションスレッドからの、およびそれが続いて形成するかもしれない任意の潜在的なスレッドからの第１のロギング情報の受信を可能にする通信インターフェイスＩＣ；
−第２のロギング情報が処理要素に発行されることを可能にする発行インターフェイスＩＰ。
【００３２】
ここで、「処理要素」はスレッドおよびプロセスを指す。図１において、後で理解されるように、ロギングプロセスＰＪおよび出力スレッドＦＳはロギング情報を受信することができるような処理要素を形成する。
【００３３】
本発明の１つの実施の形態によれば、これらのインターフェイスは「ソケット」タイプである。「ソケット」は、「Ｕｎｉｘ（登録商標）」タイプのオペレーティングシステム上で開発された当業者に周知の通信機構であるが、今日では大多数のオペレーティングシステムの下で存在する。
【００３４】
それらはたとえばＺｅｒｏＭＱに従ってもよい。ＺｅｒｏＭＱは、オペレーティングシステムに依存しないさらなるインフラストラクチャサービスを提供するために基底のオペレーティングシステムとアプリケーションとの間に挿入される「ミドルウェア」タイプのプラットフォームである。CORBA（コモンオブジェクトリクエストブローカーアーキテクチャ）などの並行プラットフォームに関しては、たとえば、ＺｅｒｏＭＱは、優れた使用環境および優れたパフォーマンス特性を提供する。コードはアプリケーションスレッドにとって非常に短いため、処理のオーバーロードがほとんどなく、ＺｅｒｏＭＱライブラリ自体内の処理も非常に高速である。したがって、ＺｅｒｏＭＱは本発明の要件に準拠し、所望のサービスが不利益かもしれないいかなる付加的処理もなしに満たされることを可能にする。
【００３５】
ＺｅｒｏＭＱが提供する機構は、ライブラリを通して、Ｃ言語におけるアプリケーションコードを使用してアクセス可能である。したがって、本発明の機構および利点はＣ言語において開発されたプロセスに関してアクセス可能である。
【００３６】
１つの実施の形態によれば、通信インターフェイスＩＣは非同期インターフェイスであり：それは、アプリケーションスレッドがロギング情報を送信し、次いでその処理を続けることを、ロギングスレッドＦＪからの肯定応答を待つことなく可能にする。
【００３７】
ＺｅｒｏＭＱを用いる実現例の枠組では、この通信インターフェイスＩＣはプッシュ／プル型であってもよい。この場合、起動で、ロギングスレッドは、「プル」タイプのソケットを形成する。アプリケーションスレッドＦ１、Ｆ２は、次いで、ロギングスレッドＦＪの「プル」ソケットに接続された「プッシュ」タイプのソケットを介してロギング情報を送信してもよい。
【００３８】
通信インターフェイスＩＣを形成する２つのタイプのソケット間において、「ｉｎｐｒｏｃ（インプロセス）」プロトコルなどのようなスレッド間およびプロセス内トランスポートプロトコルが確立されてもよい。このプロトコルは同じプロセス内でスレッド間のメッセージの送信を可能にし：情報は、プロセスと関連付けられるコンテキストに属するメモリによって直接送信される。したがって、この機構はいかなる入力／出力も生成せず、したがって本発明に従う方法の高性能に寄与する。
【００３９】
発行インターフェイスＩＰは、ロギングスレッドＦＪ内に形成される「ｐｕｂ（発行）」タイプのソケットを含んでもよい。処理要素（プロセスまたはスレッド）ＰＪ、ＦＳは、ロギングスレッドＰＪの「ｐｕｂ」ソケットにサブスクライブするために「ｓｕｂ（）」タイプのソケットを形成することができる。したがって、ＺｅｒｏＭＱによって管理される「発行・サブスクライブ」モデルは、メッセージが、既にサブスクライブされたすべての処理要素に送信されることを可能にする。
【００４０】
本発明の１つの実施の形態によれば、プロセス（Ｐ１）の開始において、アプリケーションスレッドは、その実行を続ける前に、このロギングスレッド（ＦＪ）の初期設定を待つ。
【００４１】
それがロギングスレッドＦＪの実行を開始すると、プロセスＰ１の（メイン）スレッドは、ロギング情報を受信しなければならないある数の処理要素を示すことができる。それは、このサブスクライブされた処理要素の数が到達されたとき、ロギングスレッドＦＪから肯定応答を受信するにすぎないことになる。一旦、肯定応答が受信されると、次いで、スレッドはその実行を続けることができる。
【００４２】
同様に、ロギングスレッドＦＪは、それを、ロギング情報を受信しなければならない数の処理要素と同期させることによって、初期化される。
【００４３】
この目的のため、ロギングスレッドＦＪは同期情報を発行することができる。この情報の受信で、それを受信した処理要素は、ロギングスレッドに肯定応答を送信することになる。後者は、受信された肯定応答をカウントし、規定数がいつ到達されるかを容易に判断することができる。
【００４４】
この同期段階では、ロギング情報が失われないことが保証され：実際、ロギングスレッドＦＪと処理要素との間の接続の確立は、ある時間を取り得る。さらに、処理要素それら自体も初期化のプロセスにあり得る。この時間中において、ロギングスレッドＦＪがロギング情報を直ちに送信し始めた場合、後者は、受信処理要素によって発行されるロギング情報の送信における肯定応答がないために、失われるであろう。このように肯定応答がないことは、十分な性能特性が達成されることを可能にする。
【００４５】
しかしながら、ある状況では、いかなるロギング情報も失わないことは重要または重大にさえなり得る。
【００４６】
この実現例によれば、したがって、この同期機構によってすべての同期情報の受信を保証しなければならない処理要素の数を特定することができる。
【００４７】
この数の要素は、サブスクライブされた処理要素の組のサブセットを決定し、なぜならば一旦初期化段階が終わると、他の処理要素がロギングスレッドＦＪの発行にサブスクライブすることが完全に可能であるからである。しかしながら、後者はロギングスレッドＦＪの第１の発行を逃すかもしれない。
【００４８】
本発明に従うロギング方法は、プロセスＰ１の実行のためのステップを備える。先に記載されたように、この実行は、少なくとも１つのアプリケーションスレッドＦ１、および１つのロギングスレッドＦＪの実行を必要を伴う。Ｃ言語で書かれたプロセスの場合、このアプリケーションスレッドＦ１は関数のmain()の実行に対応してもよい。
【００４９】
一旦初期化段階が終わると、アプリケーションスレッドはソフトウェアアプリケーションのコードを実行する。
【００５０】
方法は、アプリケーションスレッド内にロギングイベントを検出すること、および第１のロギング情報ｅ１、ｅ２をロギングスレッドＦＪに直ちに送信することにある。
【００５１】
ロギングイベントの検出はそれ自体公知の技術であり、それは、ある条件が満たされるとロギングイベントをトリガするために「ロガー」をコードに挿入することにある。これらの条件は、非常に単純に、（コードの動作の順序を守るために）コード内の正確なポイントを通過すること、またはそうでなければエラーの状況などであってもよい。
【００５２】
アプリケーションスレッドＦ１、Ｆ２によって生成されたこのロギング情報は、それを、ロギングスレッドＦＪによって発行される第２のロギング情報と区別するために、ここでは「第１のロギング情報」と呼ばれる。
【００５３】
この情報は名称およびレベルのみを含んでもよい。１つの実施の形態によれば、この第１の情報はこの名称およびこのレベルのみを含む。
【００５４】
名称は、アプリケーションコード内でロガーを識別する一続きの文字であってもよい。
レベルは、一般的に、イベントの重大性の度合を識別する整数である。このレベルは先に規定されたリストに属してもよく、それは以下を含んでもよい：
−「重大」：一般に、プロセスの終了に至る重大なエラーを示す。
【００５５】
−「エラー」：通常のエラーを示す。
−「警告」：重要でないエラーを示す。
【００５６】
−「出力」：通常のメッセージ（エラーに関連付けられない）を示す。
−「情報」：アプリケーションの（開発者および試験者だけでなく）ユーザの注意を喚起するメッセージを示す。
【００５７】
−「デバッグ」：アプリケーションの試験者（または「デバッガー」）に向けた、より詳細なメッセージを示す。
【００５８】
−「トレース」：最も詳細なレベルに関連付けられるメッセージを示す。その使用は、明らかにアプリケーションの開発段階のために意図される。
【００５９】
このリストは当然のことながら非網羅的である。多くの他のレベルがアプリケーションの開発者によって規定されてもよい。
【００６０】
本発明の機構によって考慮されるためには、開発者または試験者に対して意図されるすべての出力がこの形式に適合することが重要である。したがって、開発者にとっては、特にＣ言語のprintf（）関数による直接出力を避けることが重要である。それらは、たとえば「出力」レベルと置換されてもよい。
【００６１】
この第１の情報はさらに以下のものを含んでもよい：
−ロギングイベントの発生のタイムスタンプ；
−プロセスＰ１の識別子；
−実行コンテキストについての他の情報：カーネルのスレッドに対する識別子、ソフトウェアアプリケーション名、ファイル名、アプリケーションコードの行番号、実行中の関数の名称など。
【００６２】
本発明によれば、アプリケーションスレッドは、この第１のロギング情報を通信インターフェイスＩＣを介してロギングスレッドＦＪに直ちに送信する。先に理解されたように、このインターフェイスは非同期であり、いかなる肯定応答も必要としない。また、一旦送信が（ロギングスレッドによる受信について心配することなく）実行されると、アプリケーションスレッドＦ１、Ｆ２は、直ちにアプリケーション処理を続けることができるような態様で、どのようなロックもインストールされない。
【００６３】
１つの実施の形態によれば、どのような他の処理も、ロギングイベントの検出と第１のロギング情報の生成との間には適用されない。
【００６４】
１つの実施の形態によれば、フォーマット化処理動作のみが適用される。
いずれの場合も、本発明によれば、アプリケーションスレッドは入力/出力機構を設定せず：これらの機構はロギングスレッドＦＪによって実現され、したがってアプリケーションスレッドＦ１、Ｆ２の外部に転送される。
【００６５】
その結果、アプリケーションスレッドについて、追加費用は最小限に減じられる。
本発明の１つの実施の形態によれば、アプリケーションコードはモジュールに分割される。各モジュールは名称または識別子と関連付けられ、それはロガーの名称に組入れられてもよい。
【００６６】
たとえば、モジュール「Module1」では、ロガーの名称は、「Module1.logger1」、「Module1.logger2」などである。
【００６７】
この機構は、さまざまなロギングイベントがより明瞭に名付けられることを可能にし：チェーンの終わりで、イベントが発生したコード内の位置は、したがって、その名称に含まれるモジュール名の関数として直接的に決定されてもよい。
【００６８】
ロギングスレッドＦＪは、アプリケーションスレッドＦ１、Ｆ２によって生成された第１のロギング情報を非同期態様で受信する。そのとき、その役割は、アプリケーションスレッドから受信された第１のロギング情報およびおそらくは相補的な情報から開始する第２のロギング情報を生成することである。この相補的な情報は、プロセスのアプリケーションスレッドのすべてに共通の情報であってもよい。
【００６９】
ロギングスレッドＦＪによって実現される処理は、この第２のロギング情報の生成に制限されてもよい。生成は、一方では、潜在的な相補的情報の追加を含んでもよいが、処理要素によるその利用を可能にする所定のフォーマットに従って、条件付けも含むことができる。
【００７０】
このフォーマット化は、非常に単純であってもよく、第２の情報が、用いられるコンピュータプログラミング言語から独立したフォーマットにあるように、もっぱらあるフォーマット化からなってもよい。
【００７１】
この第２の情報は、その後発行インターフェイスＩＰを介してロギングスレッドＦＪによって発行される。次いで、それは、先に記載されたように、ロギングスレッドに既に登録されている１つ以上の処理要素Ｆｓ、ＰＪ）によって受信されることができる。
【００７２】
これらの処理要素は、プロセスＰ１に属する出力スレッドＦｓを含んでもよい。この出力スレッドは、表示端末（画面等）上、メモリ、特に大容量メモリなどに保存されたファイル内、などに、第２のロギング情報の出力を形成するよう設計されてもよい。
【００７３】
これらの出力機構は、ハードウェアとの必要とされる対話のため、および一般に肯定応答の必要性（スレッドは、情報が実際にハードディスクなどに保存されたことを確認する必要がある）のため、処理時間において高くつく。
【００７４】
本発明により、これらの機構は、ロギングスレッドの動作シーケンスと並行する態様でその動作シーケンスに従うアプリケーションスレッドに影響を与えない。
【００７５】
処理要素は、さらに、前記プロセス（Ｐ１）とは異なるロギングプロセス（ＰＪ）を含んでもよい。
【００７６】
このプロセスは、さらに、出力スレッドＦＳと同じ態様で出力機構を実現してもよい。
さらに、それは、ロギング情報の利用のためのより複雑な機構：フィルタ処理などを実現してもよい。
【００７７】
本発明の１つの実施の形態によれば、プロセスＰ１が複製されると、ロギングスレッドＦＪおよび潜在的な出力スレッドＦＳは終了され、次いで、最初の親プロセスＰ１内で再起動される。娘プロセス内において、これらの２つのスレッドは再起動されない（以下に記載されるように、それらは「ファイナライズ済み」状態に入る）。実際、非常に頻繁に、娘プロセスは、娘プロセスの内容を新しいプログラムによって置き換えて「潰す」関数「exec（）」の実行をトリガし：したがって、ロギングスレッドおよび出力スレッドの自動再起動をトリガする必要はなく、それは逆効果でさえあるかもしれない。
【００７８】
複製はまたは「fork」は、「Ｕｎｉｘ（登録商標）」タイプのオペレーティングシステムで動作するソフトウェアアプリケーションまたはＰｏｓｉｘ規格に準拠したソフトウェアアプリケーションで新しいプロセスを作成するための機構である。
【００７９】
いくつかのスレッドを含むプロセス（「マルチスレッドプロセス」）の複製は重大な問題を提起する。この問題は、特にＰｏｓｉｘ規格、ＩＥＥＥ１００３．１、特に「Rationales」の部分に記載されている。
【００８０】
本発明によって実現される機構は、それが回避されることを可能にする。
さらに、複製「fork（）」を最良に管理するために、状態機械の管理を設定してもよい。
【００８１】
図２は、ロギングスレッドＦＪのそのような状態機械を示す。スレッドＦＪは５つの主な状態であり得ることが考えられる。これらの状態は従来、
−「未設定」：「開始されていない」状態に対応し、これは、スレッドが、アプリケーションスレッドがその初期化をトリガする前であってもよい状態に対応する。
【００８２】
−「初期化中」：スレッドの初期化状態に対応し、その間に前述の同期化ステップが特に行われる。
【００８３】
−「初期化済」：ロギングスレッドの通常動作に対応する。
−「ファイナライズ中」：ロギングスレッドの終了に対応する。
【００８４】
−「ファイナライズ済み」：スレッドが終わった状態に対応する。
ある状態では、本発明のこの実施の形態によれば、複製は禁じられる。これは、「初期化中」状態および「ファイナライズ中」状態に対する場合であり：矢印「fork（）」は「不正な」状態に至る。
【００８５】
特定の状態「未設定」および「ファイナライズ済み」では、複製が許可されてもよく、特定の処理動作を発生させなくてもよい。矢印「fork（）」は現在の状態にループして戻る。
【００８６】
「初期化済」状態では、複製は、ロギングスレッドを終了させるために遷移を状態「ファイナライズ中」に移行する。
【００８７】
潜在的な出力スレッドＦＳについて同じことが言える。
一旦スレッドが終わると、プロセスを複製することができる。
【００８８】
一旦、複製が実行されると、スレッドＦＪおよびＦＳは再起動されてもよい。親プロセス（言いかえれば初期プロセスＰ１）では、スレッドは、それらが複製前であった状態、言いかえれば「初期化済」状態で再起動される。娘プロセスでは、スレッドは「未設定」状態で開始し：次いで、娘プロセスのアプリケーションスレッドはそれに状態を変更させるためにその初期設定を起動しなければならない。
【００８９】
さらに、ＰｏｓｉｘまたはＵｎｉｘ（登録商標）タイプのシステムの下で動作するプロセスＰ１は、信号を受信することができる。これらの信号は、信号ＳＩＧＩＮＴ、ＳＩＧＴＥＲＭ、ＳＩＧＱＵＩＴ、ＳＩＧＳＥＧＶ、ＳＩＧＢＵＳなどのような、プロセスを終了させるために与えられてもよい。
【００９０】
このような信号がロギングスレッドＦＪによって受信されると、後者はそれらをそれらの性質に応じて処理するかどうかを選択してもよい。たとえば、信号ＳＩＧＩＮＴ、ＳＩＧＴＥＲＭおよびＳＩＧＱＵＩＴは、アプリケーションスレッドによって処理される必要があると考慮されてもよく、したがって、ロギングスレッドによって考慮されなくてもよい。それは、他方、ＳＩＧＳＥＧＶおよびＳＩＧＢＵＳなどの他のタイプの信号を考慮してもよい。
【００９１】
そのような信号の受信と同時に、ロギングスレッドＦＪは、これはロギングイベントを構成すると考慮し、次いで、この信号と関連付けて、ロギング情報を発行してもよい。
【００９２】
続いて、それはもう一度この信号およびその「通常の」処理をトリガしてもよい。信号の通常の処理は、典型的には「ハンドラ」と呼ばれ、この信号と関連付けられる処理コードによって提供される。この信号ＳＩＧＳＥＧＶまたはＳＩＧＢＵＳの通常の処理はプロセスの終了に至る。
【００９３】
したがって、この機構によって、プロセスは、終わることにある、期待される挙動を採用するが、このイベントの受信にリンクされるロギングも確実に行われ：さらに、処理要素がロギングスレッドにサブスクライブされる場合には、それにプロセスＰ１の終了の原因が通知される。
【００９４】
信号がアプリケーションスレッドによって受信される場合には、後者はそれがロギングイベントを構成すると判断してもよい。この目的のため、ある特定のコードが「ハンドラ」として信号に関連付けられてもよく：所与の信号の受信で、この特定のコードがオペレーティングシステムによってトリガされる。
【００９５】
この特定のコードは通信インターフェイスＩＣを介してロギングスレッドに（第１の）ロギング情報の即時送信を可能にする。
【００９６】
このコードは、さらにロギングスレッドがこの第１のロギング情報から開始する第２のロギング情報を生成し、発行インターフェイスを介してそれを発行することを可能にする待ち時間を含んでもよい。
【００９７】
そのときのみ、特定のコードは、プロセスの終了を実現するかまたはプロセスそれ自体を終了するために、通常の処理コードを呼出すことができる。
【００９８】
したがって、サブスクライブされた処理要素は、プロセスの終了の原因を通知されることができる。
【００９９】
言うまでもなく、本発明は、説明され図示された例および実施の形態に限定されず、当業者がアクセス可能な多数の変形例が可能である。
【図１】
0006498770.tif 000002
【図２】
0006498770.tif 000003