(57)【要約】  モニタプログラムは、コンピュータの再起動時に１セットのクライアントプロセスを実行し、コンピュータ上で走るクライアントプロセスを開始、停止および監視し、および／または、自動的にプロセスのクラッシュを検出してリカバリする。モニタプログラムは、クライアントプロセスが開始されたときに生成する監督スレッドを使用してクライアントプロセスを監視し、そのクライアントプロセスのハンドルを使用してその終了を検出する。クライアントプロセスの終了が検出されたら、そのクライアントプロセスがクラッシュしたのか正常に終了したのかを判定するためにモニタプログラム内にあるプロセス状態テーブルがチェックされる。終了がクラッシュの結果であった場合には、モニタプログラムは、事前に設定されたプランに従って自動的にクラッシュリカバリを実行することができる。
2008546077.tif 000002
【特許請求の範囲】
【請求項１】
プロセス制御モジュールおよびクラッシュ検出リカバリモジュールを含むモニタプログラムを格納するメモリと、このメモリに接続されており前記プロセス制御モジュールおよび前記クラッシュ検出リカバリモジュールを実行して所定の機能を実行するよう構成されたプロセッサとを備えるコンピュータであって、
前記プロセス制御モジュールはクライアントプロセスの外部で規定された前記メモリに格納されたルールに基づいてそのクライアントプロセスを開始または停止し、前記プロセス制御モジュールはオペレーティングプラットフォームにクライアントプロセスの開始を要求することによってそのクライアントプロセスを開始し、開始されたクライアントプロセスのためのハンドルをオペレーティングプラットフォームから受信し、第１の監督スレッドを生成してそれを前記ハンドルと共に開始されたクライアントプロセスに組み込み、開始されたクライアントプロセスの実行状態の監視に使用するために第１の監督スレッドを前記プロセス制御モジュールに格納し、前記プロセス制御モジュールは前記監督スレッドを通じて関連するクライアントプロセスが終了したことを検出したらそれに応えてエグジット通知イベントを生成し、前記プロセス制御モジュールはそのクライアントプロセス内の第２の監督スレッドのプロセス間通信オブジェクトにこのプロセス間通信オブジェクトのハンドルを使用して合図することによってそのクライアントプロセスを停止し、
前記クラッシュ検出リカバリモジュールは開始されたクライアントプロセスの１つ以上のプロセスに対して定められたクラッシュリカバリプランを格納し、前記クラッシュ検出リカバリモジュールはプロセス状態テーブルを管理し、クライアントプロセスが正常に終了した場合には前記プロセス制御モジュールから正常終了信号を受信し、停止したクライアントプロセスからこの停止したプロセスに対応する第１の監督スレッドを通じてこのクライアントプロセスが停止したことを示すエグジット通知信号を受信し、前記クラッシュ検出リカバリモジュールは、前記プロセス制御モジュールから前記エグジット通知信号を受信したらそれに応えて、停止したクライアントプロセスが前記プロセス状態テーブルの中に対応する正常終了データを持っているかどうかをチェックすることによって、そのプロセスの終了が正常であったかどうかを判定し、前記クラッシュ検出リカバリモジュールはコンピュータがクライアントプロセスのクラッシュからどのようにリカバリするかを規定する少なくとも１つのクラッシュリカバリプランを格納し、前記プロセス制御モジュールはクライアントプロセスの終了がクラッシュの結果生じたものであると判定した場合には前記クラッシュリカバリプランを実行することを特徴とするコンピュータ。
【請求項２】
前記メモリは、前記プロセス制御モジュールからクライアントプロセスが終了したことを示すエグジット通知信号を受信し、前記クラッシュ検出リカバリモジュールにそのエグジット通知信号を通知するイベントハンドラを更に格納し、前記クラッシュ検出リカバリモジュールは、前記プロセス制御モジュールからのエグジット通知信号に応えて対応するクライアントプロセスの終了が正常であったかどうかを判定することを特徴とする請求項１に記載のコンピュータ。
【請求項３】
前記プロセス制御モジュールは、ルールが許すときに前記プロセス制御モジュールによって実行される開始リクエストおよび停止リクエストを格納する待ち行列を有することを特徴とする請求項１に記載のコンピュータ。
【請求項４】
前記モニタプログラムは、コンピュータを起動する際に実行される開始リクエストおよび停止リクエストが設定された初期化プログラムを更に含み、前記初期化プログラムは設定された開始リクエストおよび停止リクエストをコンピュータを起動する際に実行するために前記待ち行列に入力することを特徴とする請求項３に記載のコンピュータ。
【請求項５】
前記待ち行列に入力された開始リクエストおよび停止リクエストの少なくとも１つは実行中のプロセスを発信源とするものである、ことを特徴とする請求項１に記載のコンピュータ。
【請求項６】
プロセッサと、該プロセッサに結合したメモリとを備えるコンピュータであって、
前記メモリは当該コンピュータ上で走るクライアントプロセスのための対応する監督スレッドを有するモニタプログラムを格納し、前記監督スレッドは対応するクライアントプロセスの外部で動作し、前記プロセッサが対応するクライアントプロセスをそのプロセスの外部で監視することを可能にすることを特徴とするコンピュータ。
【請求項７】
前記モニタプログラムは、オペレーティングプラットフォーム上で走るクライアントプロセスの開始に応答してそのオペレーティングプラットフォームからのハンドルを使用し、そのクライアントプロセスの監視に使用するために前記監督スレッドをその中に前記ハンドルを含む形で生成する開始プログラムを含むことを特徴とする請求項６に記載のコンピュータ。
【請求項８】
前記開始プログラムはクライアントプロセスが開始できるかどうかを判定するためにこの開始プログラムによって使用される１つ以上のルールを含み、前記開始プログラムはクライアントプロセスが開始できることをそのクライアントプロセスの外部で定められた１つ以上のルールに基づいて決定したらそれに応えてクライアントプロセスの開始に着手する、ことを特徴とする請求項７に記載のコンピュータ。
【請求項９】
当該コンピュータは、入力装置と、出力装置と、インタフェース装置とを更に備え、
前記モニタプログラムは、監督スレッドと、クライアントプロセスに対応するハンドルおよび対応するクライアントプロセス内に保持されるプロセス間通信オブジェクトのハンドルの１つ以上のハンドルを使用してクライアントプロセスを制御するために、前記プロセッサによって実行される別の実行中のプロセス、前記入力装置および前記出力装置を介してユーザ、前記インタフェース装置を介して外部機器、またはそれらの組み合わせによってトリガーすることができる開始プログラム、停止プログラム、またはその両方を含むことを特徴とする請求項６に記載のコンピュータ。
【請求項１０】
前記メモリは、当該コンピュータを起動する際に前記プロセッサによって開始される１つ以上のプロセスから成るプロセス群を規定する初期化プログラムを格納することを特徴とする請求項６に記載のコンピュータ。
【請求項１１】
前記モニタプログラムはクライアントプロセスのクラッシュからリカバリするためのプランを規定するクラッシュリカバリプランを格納するクラッシュ検出リカバリモジュールを更に含み、前記プロセッサは前記リカバリプランを実行して当該コンピュータのユーザの関与を要求することなくクライアントプロセスのクラッシュから自動的にリカバリすることを特徴とする請求項６に記載のコンピュータ。
【請求項１２】
前記クラッシュ検出リカバリモジュールは、クライアントプロセスが正常に終了したことを示すために前記モニタプログラムの停止プログラムによってセットされる正常終了フラグデータを格納するプロセス状態テーブルを含むことを特徴とする請求項１１に記載のコンピュータ。
【請求項１３】
前記モニタプログラムは、クライアントプロセスが終了する際にそのクライアントプロセスの監督スレッドからエグジット通知を受信し、そのクライアントプロセスは正常に終了したのかあるいはクラッシュの結果なのかを判定するために前記クラッシュ検出リカバリモジュールを活動化するイベントハンドラを更に含むことを特徴とする請求項１１に記載のコンピュータ。
【請求項１４】
コンピュータによって実行されるときに、コンピュータのプロセッサ上で走るクライアントプロセスを開始したらそれに応えてそのクライアントプロセスの外部に監督スレッドを、オペレーティングプラットフォームから受信したハンドルであって開始されたクライアントプロセスの実行状態を監視するためにプロセッサによって使用されるハンドルをその監督スレッドの中に含むように生成するステップを実行するコンピュータプログラムを格納することを特徴とするコンピュータ可読媒体。
【請求項１５】
前記コンピュータプログラムは、コンピュータの起動（ブート）、再起動（リブート）、リスタート、またはそれらの組み合わせに応答して初期化プログラムをプロセッサで実行する手順を更に含み、前記初期化プログラムの実行はこの初期化プログラムによって規定される１つ以上のクライアントプロセスから成るプロセス群を開始することを含み、前記監督スレッドの生成は前記初期化プログラムによって規定された各それぞれのクライアントプロセスごとに実行され、それにより各実行中のクライアントプロセスはプロセッサが各実行中のクライアントプロセスの実行状態を監視するために使用することができる対応する監督スレッドを持つことができることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
前記コンピュータプログラムはクライアントプロセスを開始するためのリクエストを受信するステップを更に含み、前記監督スレッドの生成はそのリクエストを受信したらそれに応えて実行されることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記コンピュータプログラムは、前記リクエストを受信したらそれに応えて、クライアントプロセスの外部で規定された１つ以上のルールに基づいてそのクライアントプロセスが開始できるかどうかを判定する手順を更に含み、クライアントプロセスの開始はその１つ以上のルールに基づいてそのクライアントプロセスが開始できることが決定されたらそれに応えて実行されることを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
前記リクエストは、プロセッサによって実行される別のプロセスから受信されることを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項１９】
前記リクエストは、コンピュータの入力装置を介してユーザから受信されることを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項２０】
前記リクエストは、コンピュータのインタフェース装置を介して外部機器から受信されることを特徴とする請求項１６に記載のコンピュータ可読媒体。
【請求項２１】
前記コンピュータプログラムは、オペレーティングプラットフォームがクライアントプロセスを開始した後に、そのオペレーティングプラットフォームからハンドルを受信する手順を更に含み、そのハンドルの受信は前記監督スレッドが生成される前に実行されることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項２２】
コンピュータによって実行されるときに、コンピュータのプロセッサ上で走るクライアントプロセスを開始したらそれに応えてクライアントプロセスの内部に監督スレッドを生成する手順を実行するコンピュータプログラムを格納し、前記監督スレッドは、クライアントプロセスに実行の停止を合図するために、そのプロセスをターゲットとするプロセス外部のモニタプログラムからの停止リクエストによって活動化され、前記モニタプログラムは前記停止リクエストを、前記モニタプログラムがターゲットであるクライアントプロセスと通信することを可能にするそのプロセスの監督スレッドのプロセス間通信オブジェクトのハンドルを使って、そのクライアントプロセスに送信することを特徴とするコンピュータ可読媒体。
【請求項２３】
前記プロセス間通信オブジェクトは、セマフォー（ｓｅｍａｐｈｏｒｅ）、ミューテックス（ｍｕｔｅｘ）、イベント（ｅｖｅｎｔ）、またはそれらの組み合わせの中の少なくとも１つから成ることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２４】
前記コンピュータプログラムは、
前記モニタプログラムにおいてクライアントプロセスを停止するためのリクエストを受信する手順と、
前記リクエストを受信したらそれに応えてクライアントプロセス内のプロセス間通信オブジェクトのハンドルに合図することによって前記モニタプログラムからそのクライアントプロセスを停止する手順と
を更に含むことを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２５】
前記コンピュータプログラムは、
前記リクエストを受信したらそれに応えて、クライアントプロセスの外部で規定された１つ以上のルールに基づいてそのクライアントプロセスが停止できるかどうかを判定する手順を更に含み、
クライアントプロセスの停止は、前記１つ以上のルールに基づいて、そのクライアントプロセスは停止することができると判定されたらそれに応えて実行されることを特徴とする請求項２４に記載のコンピュータ可読媒体。
【請求項２６】
前記リクエストは、プロセッサによって実行される別のプロセスから受信されることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２７】
前記リクエストは、ユーザからコンピュータの入力装置を介して受信されることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２８】
前記リクエストは、外部機器からコンピュータのインタフェース装置を介して受信されることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２９】
プロセッサと、
該プロセッサに結合したメモリとを備え、
該メモリは前記プロセッサによって実行されるクライアントプロセスのためのリカバリプランを規定するクラッシュ検出リカバリモジュールを格納し、前記クラッシュ検出リカバリモジュールは自動的にクライアントプロセスのクラッシュを検出し、当該コンピュータのユーザによるアクションを何も要求することなく前記リカバリプランを実行することによってクライアントプロセスのクラッシュからリカバリすることを特徴とするコンピュータ。
【請求項３０】
前記リカバリプランは、クライアントプロセス別に定められることを特徴とする請求項２９に記載のコンピュータ。
【請求項３１】
前記リカバリプランは、クライアントプロセス別に定められたリカバリプランの中に該当するものが存在しない場合には、クライアントプロセスのクラッシュからリカバリするために使用されるデフォルトプランであることを特徴とする請求項２９に記載のコンピュータ。
【請求項３２】
前記リカバリプランは、コンピュータが再起動（リブート）されるべきであることを示すことを特徴とする請求項２９に記載のコンピュータ。
【請求項３３】
前記リカバリプランは、クライアントプロセスがリスタートされるべきであることを示すことを特徴とする請求項２９に記載のコンピュータ。
【請求項３４】
前記リカバリプランは、前記プロセッサが少なくとも１つの他のクライアントプロセスを停止すべきであることを示すことを特徴とする請求項２９に記載のコンピュータ。
【請求項３５】
前記リカバリプランは、前記プロセッサが少なくとも１つの他のクライアントプロセスを開始すべきであることを示すことを特徴とする請求項２９に記載のコンピュータ。
【請求項３６】
コンピュータによって実行されるときに、
コンピュータのプロセッサ上で走るクライアントプロセスのクラッシュをこのクライアントプロセスの外部で検出する手順と、
自動的にクラッシュリカバリプランを実行してクライアントプロセスのクラッシュからリカバリする手順と
を実行するコンピュータプログラムを格納することを特徴とするコンピュータ可読媒体。
【請求項３７】
クラッシュを検出する手順は、
監督スレッドが、停止したクライアントプロセスのハンドルの無効化を通じて合図されたらそれに応えて、エグジット通知イベントを生成することと、
前記エグジット通知イベントを受信することと、
クライアントプロセスの正常終了フラグがそのクライアントプロセスによって終了前にセットされていることをチェックすることと、
クライアントプロセスがクラッシュしたことを前記チェックに基づいて決定することと、
前記クラッシュリカバリプランが前記決定に基づいて実行されることと
を含むものである請求項３６に記載のコンピュータ可読媒体。
【請求項３８】
前記クラッシュリカバリプランは、クライアントプロセス別に定められることを特徴とする請求項３６に記載のコンピュータ可読媒体。
【請求項３９】
前記クラッシュリカバリプランは、クライアントプロセス別に定められたリカバリプランの中に該当するものが存在しない場合には、クライアントプロセスのクラッシュからリカバリするために使用されるデフォルトプランであることを特徴とする請求項３６に記載のコンピュータ可読媒体。
【請求項４０】
前記クラッシュリカバリプランは、プロセッサにコンピュータの再起動（リブート）を指示することを特徴とする請求項３６に記載のコンピュータ可読媒体。
【請求項４１】
前記クラッシュリカバリプランは、プロセッサにクラッシュしたクライアントプロセスのリスタートを指示することを特徴とする請求項３６に記載のコンピュータ可読媒体。
【請求項４２】
前記クラッシュリカバリプランは、プロセッサに少なくとも１つの追加のプロセスの開始を指示することを特徴とする請求項３６に記載のコンピュータ可読媒体。
【請求項４３】
前記クラッシュリカバリプランは、プロセッサに少なくとも１つの追加のプロセスの停止を指示することを特徴とする請求項３６に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータ上で実行される、アプリケーション、通信プログラム、およびユーティリティプログラムなどのプロセスを監視および管理するための装置およびコンピュータ可読媒体に関する。
【背景技術】
【０００２】
コンピュータは、例えばアプリケーション、通信プログラム、およびユーティリティプログラムなどのプロセスを使用して、ユーザおよびコンピュータが指図するタスクを実行する。多くのコンピュータ環境において、各プロセスは互いに独立に実行され、その開始、終了、および他のプロセスとの相互作用に関するそれ自身のルールを規定する。このため、一般的な観点から、プロセスの実行と、他のプロセスとの相互作用を支配するルールを確認することはルールがプロセスのコードの中に隠されていることから難しい。プロセスの監視と制御がプロセスの外部で実行可能であり、プロセスの開始、終了、および相互作用を支配するルールがプロセスの外部で規定可能なシステムを実現することが望ましいと考えられる。これによりプロセスの制御は著しく単純化され、プログラマはそれらの相互作用を支配するルールを比較的直接的な方法で理解することができるであろう。
【０００３】
当業者は、コンピュータ上で実行中のプロセスは様々な理由から‘クラッシュする’可能性があることを理解している。クラッシュは、一般には、コードが正しく機能しない、あるいは予期せず終了することを意味する。クラッシュは、例えばプロセスにバグが存在する、それ対して応答するようにプログラムされていなかった入力状態をプロセスが受信する、エラーその他の原因の結果生じるデータもしくはコードの破損、メモリもしくはキャッシュのオーバフロー、コードの衝突など、数々の原因の結果生じる可能性がある。プロセスを外部から監視してプロセスの何らかの不正な働きを検出する能力がシステムに備わっていることが望ましい。さらに、クラッシュが発生した場合、ユーザに何のアクションも要求することなく自動的に、リスタート、リブート、またはその両方を実行してプロセスが容易に復旧できることが望ましい。加えて、プロセスがリスタートできる場合または機器がリブートできる場合には斯かるプロセスに対して事前に設定されたリカバリプランを用いることが望ましく、プロセスがクラッシュからリカバリする方法がフレキシブルになる。
【０００４】
従来技術の別の問題は、１つのプロセスが他のプロセスを制御する方法である。従来のアプローチでは、実行中のプロセスは制御された方法で別の関連プロセスを開始または終了する能力は持っていないようである。当該特定のインスタンスの外部のコードから後で終了する能力を保持し、クラッシュが発生した場合のリカバリ手続きを事前設定するといった方法でプロセスを開始することが可能なことが望ましい。プロセスの終了が要求される場合、プロセスを終了する前に設定可能な（configurable）エグジット処理（exit process）を実行する能力を提供することが更に望ましいであろう。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明の課題は、上述した従来技術に伴う問題を克服することが可能な、コンピュータ上で実行される、アプリケーション、通信プログラム、およびユーティリティプログラムなどのクライアントプロセスを監視および管理するための装置、コンピュータ可読媒体、および方法を提供することにある。
【課題を解決するための手段】
【０００６】
本発明は、上記課題を解決するため、プロセッサとこのプロセッサに結合したメモリとを備えるコンピュータを提供する。メモリはコンピュータ上で走るプロセスのための対応する監督スレッド（supervisory thread）を有するモニタプログラム（monitor program）を格納する。監督スレッドは、対応するプロセスとは独立に、または対応するプロセスの外部で動作し、このおかげでプロセッサは監督スレッドを使用して対応するプロセスを外側から制御することができる。モニタプログラムは、オペレーティングプラットフォーム（operating platform）上で走るプロセスの開始に応答してオペレーティングプラットフォームからハンドル（handle）を受け取るとともに、プロセスを監視するのに使用するハンドルを組み込む形で監督スレッドを生成するための開始プログラムを含みうる。プロセスはモニタプログラムがそのプロセスと相互作用することができるようにカスタマイズすることができる。プロセスの内部に監督スレッドを加えることが可能であり、その監督スレッドはモニタプログラムと対応するプロセスの両方に知られている固有のプロセス間通信オブジェクト（例えばセマフォー（semaphore）、ミューテックス（mutex）、イベント（event）など）を監視する。モニタプログラムは、リクエストを使って、プロセス間通信オブジェクト（interprocess communication object）に合図し、それを契機にプロセスはカスタマイズされた終了手続きを実行してそれ自身を終了するような形で、対応するプロセスを終了させることができる。終了手続きは、終了前に、データを保存すること、または他のタスクを実行することを含む場合がある。開始プログラムおよび停止プログラムのトリガー（開始）は様々な方法で起こり得る。例えば、プロセッサによって実行される別の実行中のプロセス、コンピュータの入力装置および出力装置で与えられるユーザインタフェースを介したユーザ、コンピュータのインタフェース装置を介してコンピュータに結合した外部機器、あるいはそれらの組み合わせがトリガーの原因となる場合がある。モニタプログラムは開始リクエストおよび停止リクエストを、様々な環境下においてリクエストのターゲットであるプロセスが開始可能かどうかまたは停止可能かどうかを規定するプロセス外部の１つ以上のルールに基づいて実行する。メモリはコンピュータの起動時にプロセッサによって開始される１つ以上のプロセスから成るプロセス群を規定する初期化手続きを格納することができる。モニタプログラムはクラッシュリカバリプランを格納するクラッシュ検出リカバリモジュール（crash detection and recovery module）を更に含みうる。クラッシュリカバリプランはプロセスのクラッシュからリカバリするためにプロセッサによって実行される１つ以上の機能を規定する。プロセッサはコンピュータのユーザの関与を要求することなくリカバリプランを実行してプロセスのクラッシュから自動的にリカバリする。クラッシュ検出リカバリモジュールは、プロセスが正常に終了する場合にモニタプログラムによってセットされるが、クラッシュが原因でプロセスが終了する場合にはプロセスによってセットされない正常終了フラグ（normal termination flag）を格納するプロセス状態テーブル（process state table）を含む。モニタプログラムは、プロセスが終了する際にそのプロセスの外部監督スレッドからエグジット通知信号を受信し、そのプロセスは正常に終了したのかクラッシュの結果終了したのかを決定するためにそのエグジット通知をクラッシュ検出リカバリモジュールへ転送するイベントハンドラ（event handler）を更に含む。この決定に基づいて、クラッシュ検出リカバリモジュールはプロセスが正常に終了したのかクラッシュの結果終了したのかを決定することができる。クラッシュの結果終了したのであれば、クラッシュ検出リカバリモジュールはリカバリプランを実行することが求められる。
【０００７】
本発明は、上記課題を解決するため、プロセッサとこのプロセッサに結合したメモリとを備える別の態様のコンピュータを提供する。メモリはプロセッサによって実行されるプロセスのためのリカバリプランを定めるクラッシュ検出リカバリモジュールを格納する。クラッシュ検出リカバリモジュールは自動的にプロセスのクラッシュを検出し、コンピュータのユーザによるアクションを何も要求することなくリカバリプランに従ってプロセスのクラッシュからリカバリする。リカバリプランはプロセス別に定めることができる。代わりに、リカバリプランはプロセス別に定められたリカバリプランが存在しない場合にプロセスのクラッシュからリカバリするために使用されるデフォルトプランであることが可能である。リカバリプランは、コンピュータがリブート（reboot）されるべきか、プロセスがリスタート（restart）されるべきか、あるいはその両方かを指図することができる。
【０００８】
一部の態様として、メモリに格納されたモニタプログラムはプロセス制御モジュールからプロセスが終了したことを示すエグジット通知信号を受け取るイベントハンドラ（event handler）を更に含みうる。イベントハンドラはクラッシュ検出リカバリモジュールに、終了プロセスおよびプロセス制御モジュールからのエグジット通知信号を通知する。態様によっては、プロセス制御モジュールはルールが許すときにプロセス制御モジュールによって実行される開始リクエストおよび停止リクエストを格納する待ち行列（queue）を有する。態様によっては、モニタプログラムはコンピュータを起動する際に実行される開始リクエストおよび停止リクエストを定めるよう設定された初期化プログラムを含む。この初期化プログラムはコンピュータを起動する際に実行するための設定された開始リクエストおよび停止リクエストを待ち行列に入れる。待ち行列の中の開始リクエストおよび停止リクエストは発信元を異にすることができる。その中には例えば、別の実行中のプロセス、プロセッサに結合しておりユーザが操作する入力装置、プロセッサに結合しており外部機器からリクエストを受信するインタフェース装置、またはそれらの組み合わせが含まれる。クラッシュリカバリプランは、それぞれのプロセスがクラッシュした後に、機器がリブートされるべきかどうか、１つ以上のプロセスがリスタートされるべきかどうか、あるいは両方を決めるようなものであることが可能である。クラッシュ検出リカバリモジュールは、リブートされるまたはリスタートされる任意のプロセスのＩＤ（identity）を、コンピュータのリブートまたはプロセスのリスタートの際の実行のために待ち行列に入力されるよう、初期化プログラムに提供する。クラッシュリカバリプランの１つは、プロセス別にカスタマイズされたクラッシュリカバリプランが存在しない場合に使用されるデフォルトプランであることが可能である。クライアントプロセスに組み込まれた監督スレッドは、プロセス制御モジュールによって実行の停止を合図された場合にプロセスの終了に先だってそのプロセスによって実行されるアクションを規定する終了プログラム（termination programming）を含みうる。モニタプログラム、またはより具体的には、プロセス制御モジュールは、プロセスを開始するための開始プログラム、およびプロセスを停止するための停止プログラムを含みうる。
【０００９】
本発明は、コンピュータ上で走らせたときにモニタプログラムの上記の機能を１つ以上実行するためのコンピュータプログラム（すなわちモニタプログラム）を格納するコンピュータ可読媒体（computer-readable media）も提供する。
【００１０】
本発明をこのようにして一般的な用語で説明してきたが、ここで添付の図面を参照する。これらの図面は、必ずしも寸法通りには描かれていない。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施の最良の形態を添付図面を参照して詳細に説明する。これらの実施形態は一部にすぎず、本発明の全ての実施形態ではない。実際には、本発明は多くの異なる形態で実施が可能であり、後述する実施形態に限定されると解してはならない。もっと正確に言えば、これらの実施形態は本開示が出願の法的要件を満足するような形で提供される。なお、全体を通して類似の構成要素には類似の参照符号が付されてある。
【００１２】
［定義］
‘および／または’は、この前後の語句が意味する事物のいずれか１つ、一部、または全てを意味する。例えば、“Ａ、Ｂ、および／またはＣ”は、“Ａ、Ｂ、およびＣのいずれか１つ、一部、または全て”を意味する。
【００１３】
‘コンピュータ（computer）’は、ここでは当業者が斯かる用語と結び付けている意味と合致するように用いられる。それはメモリと、メモリ、ユーザ、または外部機器から入力データを受信してそのデータをメモリに格納された制御プログラムに基づいて処理し、入力データのそのような処理の結果として出力データを生成するプロセッサとを備える機器（デバイス）を指す。
【００１４】
‘コンピュータ可読媒体（computer-readable medium）’とは‘メモリ（memory）’のことである。
【００１５】
‘メモリ（memory）’とは、ＲＡＭ（random access memory）、ＲＯＭ（read-only memory）、ハードディスクドライブ記憶装置、テープドライブ、ＣＤ（compact disc）、ＤＶＤ（digital versatile disk ）、データをデジタルもしくはアナログ形式で、光学方式、電気方式、磁気方式、その他の方式で格納することが可能なその他のデバイスであることが可能である。‘メモリ’はその定義内に、コンピュータのプロセッサがコンピュータプログラムまたはデータをその中から読み出し、場合によってはその中に格納するために使用することが可能な任意のハードウェア、ソフトウェア、またはファームウェアを含む。
【００１６】
‘オペレーティングプラットフォーム（operating platform）’とは、メモリ、プロセッサ時間、ディスクスペース、入出力装置および周辺機器などのハードウェアリソースの割り当ておよび利用を制御するオペレーティングシステムまたはオペレーティング環境を指す。オペレーティングプラットフォームの例としては、Windows XP、Windows 2000、Windows CE、Windows 98、Windows NT、Mac OS、Unix、Linux、AIX、iSeries、zSeries、Solaris、その他の名の下にライセンスされたものが含まれる。
【００１７】
‘プロセス（process）’とは、基本的にプロセッサによって実行することが可能な任意のコードである。プロセスは、例えばアプリケーション、通信プログラム、またはユーティリティプログラムであることが可能である。
【００１８】
‘プロセッサ（processor）’は、マイクロプロセッサ、マイクロコントローラ、ＰＧＡ（programmable gate array）、ＦＰＧＡ（field programmable gate array）、ＰＡＬ（programmed array logic）、ＰＬＡ（programmed logic array）、場合によってはプログラムされた命令の下に入力データを処理して出力データを生成することが可能なその他の形態であることが可能である。
【００１９】
‘送信（sent）’もしくは‘送信（transmit）’は、１つの素子もしくはプロセスから別の素子もしくはプロセスへデータを送信することを指す。それは１つの素子から別の素子へのデータもしくは信号の送信、または斯かるデータもしくは信号を別の素子もしくはモジュールが利用できるように１つの素子もしくはモジュールによって処理した上で効率的に送信することを含みうる。
【００２０】
英単語の語尾の‘(s)’または‘(es)’または‘(ies)’は、その単語が意味するモノ（ここでは可算な有体物または無体物）が１つ以上あることを意味する。従って、‘process(es)’は‘１つ以上のプロセス’を意味する。
【００２１】
［コンピュータ１０の一般的な説明］
図１に本発明の実施の一形態によるコンピュータ１０を示す。コンピュータ１０は、プロセッサ１２、メモリ１４、入力装置１６、出力装置１８、オプションの電源２０、インタフェース装置（ＩＵ：interface unit）２２、およびバス２４を備える。プロセッサ１２は、メモリ１４、入力装置１６、出力装置１８、電源２０、およびインタフェース装置（ＩＵ）２２とバス２４を介して通信できるように接続されている。プロセッサ１２はコンピュータ１０の外部の機器とインタフェース装置（ＩＵ）２２を介して通信できるように接続することができる。
【００２２】
［プロセス２６］
メモリ１４は、プロセッサ１２によって実行可能な１つ以上のクライアントプロセス２６を格納する。クライアントプロセス（単一または複数）２６は、アプリケーション、通信プログラム、ユーティリティプログラム、またはそれらの組み合わせもしくは複数の斯かるプログラムを含みうる。各クライアントプロセス２６は、プロセッサ１２によって実行可能であり、プロセッサ１２は、そのプログラミングに従って様々な機能を実行することができる。通常の動作では、プロセッサ１２は異なるプロセス２６をそれらの間のマルチタスクによって同時に実行する。言い換えると、プロセッサ１２は、各実行中のプロセスごとにその処理時間を割り当て、その時間割当に従って順番に各プロセスを実行する。
【００２３】
ここではコンピュータ１０とそれが実行することができるプロセス２６の特定の実施形態を提供する。しかしながら、本発明の権利が及ぶ最も広い範囲または斯かるコンピュータおよびプロセスが適用可能な利用範囲を狭める意図は毛頭ない。コンピュータ１０は、例えば米国ＵＰＳ社（UPS,Inc.）の運転手や貨物取扱者（handler）が使用するＤＩＡＤ（Delivery Information Acquisition Device）といった手持ち式の携帯機器として実施可能である。ＤＩＡＤによって実行可能な１つのクライアントプロセス２６は貨物（package）の集配（集荷と配達）のためのアプリケーションである。このアプリケーションは外部機器からデータを受信するようプログラムすることができる。このデータは貨物取扱者が配送ルートに沿ってそこへ貨物を配達するアドレス（配達先）と貨物取扱者がそこから貨物を集荷するアドレス（集荷元）を示している場合がある。斯かるアプリケーションは、貨物取扱者が入力装置１６および出力装置１８を使って貨物の集配に関係するデータ、例えば立ち寄り先アドレス、集荷元アドレス、および配達先アドレスを視認することができるようにプログラムすることができる。それは貨物の集配に関係するデータ、例えば貨物取扱者が貨物を集荷または配達し終わったという事実、貨物の集荷または配達の日時を示すデータ、貨物の集荷または配達を通知するために貨物の受取人の署名を表すデータなど、を更に捕捉する場合がある。加えて、運転手が荷送人によって出荷される貨物のマニフェストを受け取ることができるようにアプリケーションをプログラムすることが可能である。コンピュータ１０はインタフェース装置２２を介して無線接続または有線接続で例えば接続架台（docking station）、追跡サーバなどの外部機器と接続して、斯かる外部機器からデータを受信するとともに、捕捉データを斯かる外部機器へ提供することができる。捕捉データは、料金請求、物流管理、貨物追跡などの目的で、斯かる外部機器に提供されることが可能である。
【００２４】
さらに、プロセス（単一または複数）２６は、コンピュータ１０がコンピュータ１０外部の機器と通信することができるようにする１つ以上の通信プログラムを含みうる。例えば、１つの斯かる通信プログラムは、例えば電源２０が充電可能なバッテリの場合であれば電源２０を充電することができる接続架台（docking station）にコンピュータ１０がプラグインされたことを検出することができる。充電ステーションに接続されたらそれに応えてプロセッサ１２は、コンピュータ１０が別の機器との通信を開始し、データの送信をトリガーする、または他の作業を実行することができるように通信プログラムを実行することができる。
【００２５】
上記の例はコンピュータ１０に実行のために格納することができるプロセス２６の例に過ぎない。当業者であれば、貨物の集配と関係があろうとなかろうと、コンピュータが適用される目的に応じて、他のアプリケーション、通信プログラム、およびユーティリティプログラムがコンピュータ１０で利用することができることは理解されよう。貨物取扱のコンテクストは例に過ぎず、本発明の開示内容は、貨物の取扱と出荷に関係なく広い目的に適用することが可能である。
【００２６】
プロセス２６には、プロセス間通信オブジェクト（interprocess communication objects）５１（例えば、イベント（event）、セマフォー（semaphore）、ミューテックス（mutex）、または他のメカニズム）を含むそれぞれの監督スレッド（supervisory threads）４４が与えられる。またオブジェクト５１にはプロセス制御モジュール３０が実行中のプロセス２６を停止することができるようにするハンドル（handles）５６が含まれる。加えて、監督スレッド４４には、モニタプログラム２８によって停止の合図が出されたときにプロセス２６によって実行される任意の処理を規定するＴＥＲＭコード（termination code）６０が与えられうる。斯かる処理は、プロセスの終了に先だってデータの保存または他のタスクの実行を含みうる。これらの機能に関しては後で詳しく述べる。
【００２７】
［モニタプログラム２８］
メモリ１４は、コンピュータ１０上で実行中の任意のプロセス２６を監視し、必要に応じて制御するための、プロセッサ１２によって実行可能なモニタプログラム２８を格納する。モニタプログラム２８は実行中のプロセスが別のプロセスの開始または停止を要求することも許可する。図１の実施形態では、モニタプログラム２８は有利にはプロセス２６とは別個のコードを含む。従ってそのコードは実行中のプロセスの１つ以上のプロセスがクラッシュした場合に斯かるプロセスを制御することができる。言い換えると、モニタプログラム２８がコンピュータ１１上で実行することができる能力はプロセス２６の状態（ステータス）に影響されない。これにより、モニタプログラム２８には１つ以上のプロセス２６がクラッシュした場合にリカバリする能力が備わる。
【００２８】
モニタプログラム２８は、プロセス制御モジュール（process control module）３０、クラッシュ検出リカバリモジュール（crash detection and recovery module）３２、およびイベントハンドラ（event handler）３４を含む。これらのモジュールについては後で個別的に詳しく説明される。
【００２９】
［プロセス制御モジュール３０］
プロセス制御モジュール３０は、（１）クライアントプロセスの任意のいずれかのプロセスを開始または停止する能力、（２）クライアントプロセスが実行中かどうかを判定する能力、（３）別のクライアントプロセスがあるクライアントプロセスを開始または停止することができるようにする能力を有する。
【００３０】
一般的なレベルにおいて、プロセス制御モジュール３０は、開始リクエスト４３を実行するための開始プログラム３８と、停止リクエスト４３を実行するための停止プログラム５４を含む。プロセス制御モジュール３０は、開始プログラム３８と停止プログラム５４によってそれぞれ適時実行するために開始リクエストと停止リクエスト４３をＦＩＦＯ（first-in-first-out）方式で格納するための待ち行列（queue）３９と、それがプロセスを開始するときに各実行中のプロセス２６ごとにそれが生成する１つ以上の監督スレッド４７も含みうる。監督スレッドのおかげでモニタプログラム２８は実行中のプロセスのクラッシュを検出することができる。開始プログラム３８は待ち行列３９から開始リクエスト４３を受け取って、ルール４１に基づいて各リクエストが実行可能かどうかを判定する。実行可能な場合、開始プログラム３８はプロセス２６の外部に監督スレッド４７を生成して、プロセスを監視してそれが停止したかどうかを判定することができるようにする。ルール４１が実行を許さない場合、開始プログラム３８はプロセスが実行されることを可能にする１つ以上の適合条件（コンティンジェンシー）が発生するまで開始リクエスト４３を却下することができる、または開始リクエスト３８を待ち行列３９に送り返すことができる。停止プログラム５４は待ち行列３９からの全ての停止リクエスト４３を処理する。停止プログラム５４が待ち行列３９から停止リクエスト３９を受信すると、それはルール７０に基づいてそのリクエストを評価して停止リクエストが実行可能かどうかを判定する。実行可能な場合、それはリクエストのターゲットであるプロセス２６のオブジェクト５１にそのプロセス間通信オブジェクト５１のハンドル５６を使って合図し、それによりプロセスは終了に先だってそのカスタマイズされた停止コード（ＴＥＲＭ）６０を実行する。また停止プログラム５４はクラッシュ検出リカバリモジュール３２にそれが停止リクエストを実行するときに停止しようとしているプロセスを通知し、そうすることでモジュール３２はプロセスの停止が正常でありクラッシュの結果でないことを知らされる。逆に、停止プログラム５４が停止リクエストを実行することをルール７０が許可しない場合には、停止プログラム５４は停止リクエストを環境がその実行を許すまでそれを待ち行列に入れることがある、またはそれは停止リクエストを全て却下することがある。停止リクエストまたは開始リクエストがプロセス制御モジュール３０に導入される方法、より具体的には、その待ち行列３９は、いくつものシナリオから生じる可能性がある。次にそれについて詳しく説明する。
【００３１】
コンピュータ１０は、コンピュータを起動する際にプロセス制御モジュール３０をロードして実行する。プロセス制御モジュール３０は、コンピュータ１０の起動に応答してプロセッサ１２によって開始される１つ以上のプロセス２６の集合を規定するＩＮＩＴ（initialization）ファンクション３６を含む。さらに、ＩＮＩＴファンクション３６は、コンピュータ１０のリスタートの際に実行される１つ以上のプロセスの集合を規定することができる。このプロセスの集合は起動時に実行されるものと必ずしも同じである必要はない。モニタプログラム２８は、オペレーティングプラットフォーム内において機器のスタートアップ時に実行されるように設定される。プロセッサは、初期プロセスの規定された集合に対する開始プログラムリクエストを開始するＩＮＩＴファンクション３６を走らせるモニタプログラム２８を実行する。２つ以上のプロセスが実行される場合、既に言及したように、プロセッサは通常、処理時間を斯かる複数の実行中のプロセスに割り当てることによって実行中のプロセス２６のマルチタスクを実行する。
【００３２】
実行中のプロセス２６は、プロセッサ１２が別のプロセスを開始または停止することを要求することができる。より具体的には、クライアントプロセス２６は、リクエストに指定されたターゲットプロセスを開始プログラム３８が開始するための、または停止プログラム５４が停止するためのリクエスト４３を、待ち行列３９へ送信することができる。リクエスト４３は、開始または停止が要求されるターゲットプロセスとリクエストを開始するプロセスを示すデータを含みうる。リクエスト４３が待ち行列３９の最後まで進むと、それはリクエストのタイプに応じて適切に開始プログラム３８または停止プログラム５４によって解析され、それによりターゲットプロセスが要求元プロセス（requesting process）によって開始または停止することができるプロセスかどうかが判定される。開始プログラム３８は、ターゲットプロセスがルール４１、７０に規定されたいくつもの基準の中の１つ以上の基準に基づいて開始または停止することができるかどうかを判定する。開始プログラム３８および停止プログラム５４の１つの態様として、要求元プロセスにはルール４１、７０を通じてターゲットプロセスを開始または停止する能力をそれに付与する特権が与えられている、あるいは逆に、要求元プロセスにはそれがターゲットプロセスを開始または停止することを禁止する制約が与えられることが可能であるが、いずれの場合もプログラマがプロセス２６に特権と制約をどのように割り当てるかによる。さらに、開始プログラム３８のルール４１または停止プログラム５４のルール７０は、２つ以上のリクエストがある１つのターゲットプロセスに発行される場合には、リクエストの発行元プロセスからのリクエストの相対的な優先順位を評価するようにプログラムされることが可能である。例えば、開始リクエストがあるプロセスから発行される場合、プロセッサ１２はモニタプログラム２８を実行してルール４１に基づいて開始プロセスが受信された時点でターゲットプロセスに対してまだ有効な停止リクエスト４３を以前に発行したプロセスが要求元プロセスからの要求より優先順位が上かどうかを判定する。優先順位が上であれば、プロセッサ１２は要求元プロセスからの開始リクエスト４３を却下することができる、あるいは例えば停止リクエストがこれより優先順位の高いプロセスによって解除されるといった１つ以上のイベントが発生するまでプロセッサ１２はその実行を延期することができる。このとき、プロセッサ１２が開始プログラム３４を実行することで、要求されたプロセスが開始される。さらに、モニタプログラム２８は、内部待ち行列３９を使用して開始リクエストおよび停止リクエストが実行される順番を与える。また必要に応じて、待ち行列は異質なリクエストを除外するよう最適化されることがある。例えば停止プログラムのリクエストの後に開始プログラムのリクエストが続く場合には、開始リクエストは処理時間を節約するためにドロップされることがある。
【００３３】
さらに、プロセス２６は、ユーザから入力装置１６を介してリクエストを受信すると同時に開始または停止することが可能であることは理解されよう。例えば、コンピュータ１０のユーザは、１つ以上のプロセス２６を開始または停止するためにプロセッサ１２に提供されるリクエスト４３を生成するよう入力装置１６を操作することができる。待ち行列３９は、リクエスト４３を開始プログラム３８または停止プログラム５４がルール４１、７０に従ってそれを実行することができるようになるまで保持する。
【００３４】
プロセス２６を開始または停止することができる更に別の方法は、外部機器によって生成されたリクエスト４３がインタフェース装置２２を介してプロセッサ１２によって受信されたことへの応答によるものである。このリクエスト４３は、開始プログラム３８がルール４１の下にまたは停止プログラム５４がルール７０の下にリクエスト４３を実行することができる時が到来するまで、待ち行列３９に保持される。
【００３５】
以上のタイプのリクエスト４３は、これらがプロセス制御モジュール３０の外側から発信されるまたはトリガーされることから、図１において外部の開始／停止リクエスト５５として示されている。
【００３６】
ＩＮＩＴファンクション３６および外部の開始／停止リクエスト４３に加えて、開始または停止リクエスト４３はクラッシュ検出リカバリモジュール３２から発信することができる。これがどのように起こるかについてはクラッシュ検出リカバリモジュール３２を取り扱う後のセクションでより詳しく説明する。
【００３７】
プロセス２６が開始されると、オペレーティングプラットフォーム４６はプロセスを特定するハンドル４８を生成し、それを開始プログラム３８に提供する。開始プログラム３８はこれが生成してプロセス制御モジュール３０に格納する監督スレッド４７からこのハンドル４８を監視する。プロセス２６が終了すると、オペレーティングプラットフォーム４６はそのハンドル４８を無効にし、それにより監督スレッド４７にプロセスが終了したことが通告される。これを契機に監督スレッド４７は、プロセスの終了が正常であったかまたはクラッシュの結果であったかを判定するためにクラッシュ検出リカバリモジュール３２によるチェックを開始するために、イベントハンドラ３４へのエグジット通知信号を生成する。
【００３８】
既に言及したように、クライアントプロセス２６はこれがモニタプログラム２８によって制御することができるように修正することが可能である。モニタプログラム２８からクライアントプロセス２６への停止リクエストの伝達は、イベント（event）、セマフォー（semaphore）、ミューテックス（mutex）、またはコンピュータ上におけるプロセス間通信のためのその他の同様なメカニズムとして実装が可能なユニークな周知のシステムＩＤ（identifier）によってサポートされる。監督スレッド（“ＳＴ”）４４はオブジェクト５１（例えばイベント（event）、セマフォー（semaphore）、ミューテックス（mutex）、その他のメカニズム）がモニタプログラム２８によって合図されるのを待機するクライアントプロセス２６−Ｒにプログラムされる。モニタプログラム２８が停止リクエストを実行する際、それはハンドル５６を使ってオブジェクト５１に合図し、それを契機に監督スレッド４４は、プロセス２６を終了するようにプログラムすることができるそのカスタム終了（ＴＥＲＭ）ファンクション６０を活動化させる。クライアントプロセスが終了するとすぐに、オペレーティングプラットフォーム４６はそのプロセスハンドル４８を無効にし、それを合図にモニタプログラム２８内の対応する監督スレッド４７はイベントハンドラ３４に渡されるエグジット通知を生成する。続いてイベントハンドラ３４はクラッシュ検出リカバリモジュール３２を活動化させる。
【００３９】
通常動作では、多くのクライアントプロセス２６がコンピュータ上で実行される。このため、図１において監督スレッド４７−１乃至４７−Ｘは、コンピュータ１０上で実行中の各プロセス２６−Ｒ１乃至２６−ＲＸに対応する。‘Ｒ’はプロセス２６が実行中であることを意味し、‘Ｘ’はコンピュータ１０上で実行中のクライアントプロセスの番号を表す。監督スレッド４７−１乃至４７−Ｘはそれらの対応するプロセス２６が実行している間はプロセス制御モジュール３０において実行状態のままである。実行中でないプロセスは図１において参照符号‘２６−ＮＲ１−２６−ＮＲＱ’が付されてある。‘ＮＲ’は実行中でないプロセス状態を表し、‘Ｑ’は実行中でないプロセスの番号を表す。
【００４０】
停止リクエスト４３を実行すると、停止プログラム５４はクラッシュ検出リカバリモジュール３２のプロセス状態テーブル７７内のプロセス２６に対応する正常終了フラグをセットする。このフラグのセッティングはプロセス２６が停止プログラムによって停止するよう要求されたことを示す。プロセス２６が実行を停止すると、そのプロセスハンドル４８はオペレーティングプラットフォーム４６によって無効化される。このハンドル無効化はプロセス制御モジュール３０の対応する監督スレッド４７への合図となり、それを契機に監督スレッド４７はイベントハンドラ３４へのエグジット通知信号を生成する。続いてイベントハンドラ３４はクラッシュ検出リカバリモジュール３２に対し、プロセス状態テーブル７７に格納された正常終了フラグを参照することによってプロセスが正常に終了したのかあるいはクラッシュしたのかを判定するよう通告する。次にクラッシュ検出リカバリモジュール３２とその動作について更に詳しく説明する。
【００４１】
［クラッシュ検出リカバリモジュール３２］
クラッシュ検出リカバリモジュール３２は、（１）プロセスがクラッシュした場合にモジュール３２がどのようにリカバリするかをクライアントプロセスが設定することができるようにする機能や、（２）コンピュータ１０上で実行中の全てのクラアインプロセスの状態（すなわち、プロセスが実行中か実行中でないかとか、プロセスが正常に終了したかクラッシュしたかとかを示すデータ）を保持する機能や、（３）クライアントプロセスのクラッシュを検出する機能、および（４）プロセスのクラッシュを検出したとき、クラッシュしたプロセスに対して設定されたリカバリプランを実行する機能、といった機能を提供する。
【００４２】
図１に示すように、クラッシュ検出リカバリモジュール３２は、コンピュータ１０内の１つ以上のプロセス２６に対するクラッシュリカバリプラン７５−１乃至７５−Ｙ（Ｙはプラン数）を格納している。クラッシュリカバリプラン７５−１乃至７５−Ｙはコンピュータ１０がカスタマイズされた方法でプロセス２６のクラッシュからリカバリすることができるように斯かる１つ以上の対応するプロセス２６に対して個別に設定することが可能である。例えば、クラッシュリカバリプラン７５は、プロセス２６がクラッシュした後に、プロセス２６のクラッシュから、コンピュータのリブート、クラッシュしたプロセスのリスタート、またはその両方のいずれでリカバリするのかを指定することができる。カスタマイズされたプラン７５がプロセス２６に対して定められていない場合には、クラッシュ検出リカバリモジュール３２は、プロセスのクラッシュからリカバリするためにデフォルトプラン７５−Ｚを使用する。
【００４３】
クラッシュ検出リカバリモジュール３２は、実行中のプロセスと実行中でないプロセスを示すプロセス状態テーブル（process state table）７７を保持管理する。クラッシュ検出リカバリモジュール３２は、終了がクラッシュでなかった事実を反映させるため、正常に終了する任意のプロセスに対して、停止プログラム５４から受信した正常終了フラグデータを更に保持する。任意のプロセスも終了するときはいつでも、その終了が正常であろうがクラッシュの結果であろうがいずれの場合も、オペレーティングプラットフォーム４６は、斯かるプロセスに対するモニタプログラムの監督スレッド４７にそのプロセスハンドル４８の無効化（invalidation）を通じて合図する。監視スレッド４７は、この合図を契機にエグジット通知イベントを通じてクラッシュ検出リカバリモジュール３２を活動化（activate）するイベントハンドラ３０に通知する。エグジット通知信号に応答して、クラッシュ検出リカバリモジュール３２は、エグジット通知の発端となっているプロセスが終了したことを示すためにそのプロセス状態テーブル７７を更新する。加えて、クラッシュ検出リカバリモジュール３２は、プロセス状態テーブル７７の対応する正常終了フラグをチェックしてプロセスが正常に終了したかどうかを判定する。正常に終了した場合、クラッシュ検出リカバリモジュール３２は、終了したプロセスに対して更なる処理を何も実行する必要はない。逆に、プロセス終了フラグがプロセスの異常終了したことを示している場合には、クラッシュからリカバリするため、クラッシュ検出リカバリモジュール３２は、クラッシュしたプロセスに対応するクラッシュリカバリプラン７５を実行する。既に言及したように、クラッシュリカバリプラン７５は、コンピュータ１０がプロセスのクラッシュからどのようにリカバリするかを規定するため、プロセス２６に対して個別に設定することが可能である。クラッシュリカバリプラン７５は図１における７５−１乃至７５−Ｙで指定されたプランのどれか１つであることが可能であり、そのプランは対応するプロセスがクラッシュした後、正常にリカバリするために、コンピュータ１０がリブートされるべきか、クラッシュしたプロセスがリスタートされるべきか、あるいはその両方が実行されるべきかを指定する。加えて、斯かるプラン７５は、クラッシュからリカバリするために他のプロセスがリスタートまたはリブートされなければならないかどうかを示すよう定めることが可能である。クラッシュリカバリプラン７５がクラッシュしたプロセスに対して個別に定められていない場合には、クラッシュ検出リカバリモジュール３２は、クラッシュからリカバリしてプロセスをコンピュータ１０上で実行できる状態に戻すためにデフォルトリカバリプラン７５−Ｚを使用することができる。クラッシュしたプロセスに対して適切なクラッシュリカバリプラン７５を実行することにより、クラッシュ検出リカバリモジュール３２がＩＮＩＴファンクション３６、待ち行列３９、またはその両方を更新するために提供する１つ以上の開始または停止リクエスト４３が生成される。
【００４４】
［イベントハンドラ３４］
イベントハンドラ（event handler）３４は、モニタプログラム２８内の監督スレッド４７によって生成されたイベントに応答する。より具体的には、プロセス２６が終了ファンクション６０および停止コード６１の実行を通じて終了（exit）するとき、終了しようとしているプロセスはモニタプログラム２８の監督スレッド４７にプロセスハンドル４８の無効化によって合図し、それを契機にモニタプログラムはイベントハンドラ３４にプロセス２６が終了したことを通知するエグジット通知イベントを生成する。加えて、プロセス２６がクラッシュによって異常終了する場合、モニタプログラム２８は同様の方法でイベントハンドラ３４に通知する。エグジット通知に応答して、イベントハンドラ３４は、クラッシュ検出リカバリモジュール３２を活動化させて、プロセス２６が終了する前にプロセス状態テーブル７７の中の正常終了フラグが停止プログラム５４によってセットされたかどうかに基づいて、プロセスが正常に終了したのかクラッシュしたのかをクラッシュ検出リカバリモジュール３２に判定させる。
【００４５】
［方法］
図２は、１つ以上のプロセス２６を、コンピュータ１０上で斯かるプロセスの外部で実行される関連する監督スレッド４７を用いて監視するための、本発明の実施の一形態による方法のフロー図である。モニタプログラム２８は図１のコンピュータ１０が実行することによって図２の方法のステップを実行するようプログラムすることができる。
【００４６】
図２のステップ２００において機器１０が起動される。ステップ２０２において、機器１０の起動に応答して、機器１０はＩＮＩＴ（初期化）プログラム３６を実行する。これを契機にプロセッサ１２は、初期化プログラム３６に定められた１つ以上のプロセス２６の集合（プロセス群）を開始する。より具体的には、その実行を通じて、初期化プログラム３６は、ターゲットプロセス２６（単一または複数）に対する１つ以上の開始リクエスト４３を開始プログラム３８に発行する。初期化プログラム３６は、起動時に特定の１セットのプロセス２６を開始するようプログラムされている。ステップ２０４において、開始プログラム３８は開始リクエスト４３をその待ち行列３９から受け取り、それを実行する。各プロセス２６が開始するごとに、開始プログラム３８は、開始されたプロセス２６のハンドル（handle）４８を機器のオペレーティングプラットフォーム（operating platform）４６から受け取る。各ハンドル４８は、プロセス外部でそれぞれのプロセス２６−Ｒの実行状態を決定する能力を与える。クライアントプロセス２６は、開始と同時に監督スレッド４４を生成するようプログラムされており、斯かる監督スレッド４４をプロセス間通信オブジェクト５１およびハンドル５６と一緒にプロセス２６に組み込む。加えて、開始プログラム３８は、監督スレッド４７を生成し、その中にオブジェクト５３をハンドル４８と一緒に組み込む。その結果、モニタプログラム２８は、プロセス２６の実行状態をプロセスの外部から監視することができる。ステップ２０６において、開始プログラム３８は、別の実行中のプロセス２６、入力装置１６のユーザ操作、インタフェース装置（ＩＵ）を介して外部機器から、あるいはそれらの組み合わせを含む様々な可能な原因の結果として生じる外部の開始リクエスト４３を受信する。斯かる開始リクエスト４３は、既に述べたように、斯かるリクエストを開始プログラム３８がそれらを実行することができる時まで待ち行列に入れることによって処理される。リクエスト４３が適用可能なルール４１に従って処理することができると仮定すると、開始プログラム３８は、（単一または複数の）斯かるプロセス２６を開始し、対応するハンドル４８をオペレーティングプラットフォーム４６から受け取り、プロセス２６が監視できるように、それぞれのオブジェクト５３およびハンドル４８を組み込んだ監督スレッド４７を生成する。既に言及したように、プロセス２６はオペレーティングプラットフォーム４６から受け取ったハンドル５６をプロセス間通信オブジェクトとともに組み込んだそれら自身の監督スレッド４４を生成する。これによりプロセス制御モジュール３０はプロセス２６を制御することができる。
【００４７】
ステップ２０８において、イベントハンドラ３４は、監督スレッド４７から、対応するハンドル４８がオペレーティングプラットフォーム４６によって無効化されるとそれに応えてエグジット通知を待機する。この無効化は、対応するプロセスが停止したことを示す。ステップ２１０において、イベントハンドラがエグジット通知を検出するとそれに応えて、クラッシュ検出リカバリモジュール３２は、エグジット通知が正常終了の結果かプロセス２６のクラッシュの結果かを判定する。クラッシュ検出リカバリモジュール３２は、このファンクションを、停止プログラム５４がプロセス２６を停止する前にプロセス状態テーブル７７内の正常終了フラグをセットしたかどうかを判定することによって実行する。正常終了フラグが停止プログラム５４によってセットされた場合、斯かるプロセスは、クラッシュしておらず、制御はステップ２０８に戻り、そこでイベントハンドラ３４はエグジット通知を待機して各実行中プロセスの監視を続行する。逆に、ステップ２１２において、そのプロセスに対する正常終了フラグがプロセス状態テーブル７７にセットされていない場合、そのプロセスはクラッシュの結果として終了している。この場合、制御はクラッシュ検出リカバリモジュール３２に残り、クラッシュ検出リカバリモジュール３２はプロセス状態テーブル７７に格納されたリスタートフラグ（restart flag）の値に基づいてリスタートされるＩＮＩＴプロセス２６のセットを更新する。それはクラッシュしたプロセス２６に対して定められたクラッシュリカバリプラン７５に従ってリブートフラグおよび／またはリスタートフラグもセットする。クラッシュしたプロセス２６に対して指定されたリカバリプラン７５が存在しない場合には、クラッシュ検出リカバリモジュール３２はデフォルトプラン７５−Ｚを使用してクラッシュ状態からリカバリするようリブートおよび／またはリスタートを適切にセット（またはリセット）する。ステップ２１６において、クラッシュ検出リカバリモジュール３２は、クラッシュリカバリプランがコンピュータ１０のリブート（再起動）を要求しているかどうかを決定する。要求している場合には、プロセッサ１２によって実行される処理は機器を起動するステップ２００に進む。逆に、リブートフラグがセットされない場合には、ステップ２１８において、プロセッサ１２は、クラッシュ検出リカバリモジュール３２を実行し、実行中のプラン７５についてプロセス状態テーブル７７の中でリスタートを要求していると特定される任意のプロセスをリスタートさせる。クラッシュ検出リカバリモジュール３２のプロセッサ１２による実行がどのプロセスもリスタートを要求していないことを示す場合、制御はステップ２０８に進み、イベントハンドラ３４はエグジット通知を待機して実行中プロセス２６の監視を続行する。クラッシュ検出リカバリモジュール３２がステップ２１８においてリスタートが必要であると判断する場合、クラッシュ検出リカバリモジュール３２は、待ち行列に入るその開始リクエスト４３を、ステップ２１４においてリカバリプランに指定されたプロセスをステップ２０４において開始するために開始プログラム３８に送信する。ステップ２０４の実行の後、制御はステップ２０８に進み、そこでイベントハンドラ３４は実行中のプロセス２６を対応する監督スレッド４７を用いて監視する。
【００４８】
図３は機器１０上でプロセス２６を開始する本発明の実施の一形態による方法のフロー図である。ステップ３００において、開始リクエスト４３がターゲットプロセス２６−ＮＲの開始を要求しているモニタプログラムまたはクラアントプロセス２６−Ｒによって発行される。開始リクエスト４３は待ち行列３９に格納され、そこで開始プログラム３８によるサービスを待機する。ステップ３０２において、開始プログラム３８は新たなプロセス２６を開始する。開始プログラム３８は、リクエストされたプロセス２６の開始をオペレーティングプラットフォーム４６に要求することによってそれを行う。開始プログラム３８は開始されたプロセスのハンドル４８をオペレーティングプラットフォーム４６から受け取り、そのハンドルをメモリに保存する。クラアントプロセス２６は、監督スレッド４４をオブジェクト５１およびハンドル５６と共に組み込み、それがモニタプログラムによって制御することができるようにする。ステップ３０４において、開始プログラム３８は、オブジェクト５３およびハンドル４８を含む休眠監督スレッド４７をモニタプログラム２８内に生成し、休眠監督スレッド４７は開始されたクラアントプロセスのハンドルが無効化されるとき（すなわちプロセスが終了するとき）に活動化する。監督スレッド４７が活動化すると、監督スレッド４７はイベントハンドラ３４にエグジット通知を発行する。続いてイベントハンドラ３４は、クラッシュ検出リカバリモジュール３２に対して、プロセスの終了（exit）が正常だったかクラッシュの結果だったかを決定するよう勧告する。
【００４９】
図４は機器１０上でプロセスを停止する本発明の実施の一形態による方法のフロー図である。ステップ４００において、モニタプログラム２８またはクライアントプロセス２６−Ｒは、別のプロセス２６−ＮＲを標的にした停止リクエスト４３を発行する。停止リクエスト４３は、停止プログラム５４がそれを実行することができる時まで待ち行列に入れられる。ステップ４０２において、停止プログラム５４は、プロセスが停止された後にそれがリスタートされるべきかどうかを決定する。この決定はルール７０、クラッシュリカバリプラン７５、またはその両方に基づいて行われることがある。ステップ４０２において、停止プログラム５４がプロセスがリスタートされるべきでないと決定する場合、ステップ４０４においてそれはこのプロセスが停止された後にそれがリスタートされるべきでないことを示すためにこのプロセスに対応するフラグをセットする。逆に、ステップ４０２においてプロセスが停止された後にそれがリスタートされるべきであると停止プログラム３８が決定する場合、ステップ４０６において停止プログラムは斯かるプロセスが停止された後にそれはリスタートされるべきであることを示すためにテーブル７７内の対応するフラグをセットする。ステップ４０８において、停止プログラム３８は、プロセッサ１２によって実行され、ターゲットプロセスが停止された後に機器１０がリブートされるべきかどうかを決定する。リブートされるべきでない場合、ステップ４１０において停止プログラム５４はターゲットプロセスが停止された後に機器１０はリブートされるべきでないことを示すために対応するフラグをセットする。逆に、ステップ４０８においてターゲットプロセスが停止された後に機器１０はリブートされるべきであると停止プログラム５４が決定する場合、ステップ４１２において停止プログラム５４はプロセス状態テーブル７７内の対応するフラグをそれ相応にセットする。ステップ４１４において、停止プログラム５４は、クライアントプロセスの監督スレッド４４内のプロセス間通信オブジェクト５１に合図して、それを契機に監督スレッド４４はターゲットプロセス２６に停止リクエストを発行する。
【００５０】
図５は機器１０上で実行中のクライアントプロセス２６を停止する本発明の実施の一形態による方法のフロー図である。ステップ５００において、クライアントプロセス２６は、通常のクライアント処理をそのコードに従ってそれが走るがままに実行する。停止リクエストがない場合、ステップ５００の通常のクライアント処理はプロセス２６の正常終了に進む。しかしながら、この場合、ステップ５０２において、停止プログラム５４はプロセス２６の監督スレッド４４に停止リクエストを発行する。停止リクエストは、プロセス２６の監督スレッド４４を、監督スレッド４４のプロセス間通信オブジェクト５１に合図することによって活動化する。ステップ５０４において、プロセス２６は、停止コード６１の実行前にそれが実行を停止する前に任意のカスタマイズされたエグジット処理をそのプログラミング６０に従って実行することができる。
【００５１】
［代替形態］
当業者であれば、本発明の範囲を逸脱することなく可能な多くの変形形態が存在することは理解されよう。例えばクラッシュリカバリプラン７５をクラッシュ検出リカバリモジュール３２に格納するのではなく、斯かるプランを、それぞれのプロセス２６の監督スレッド４４または４７内などの、開示されたモジュール内外の、メモリ１４の他のどこかに格納することが可能である。同様に、プロセス２６が対応する監督スレッド４４によってエグジットするよう合図されたときに実行されるコードを規定する終了コード６０は実行中のプロセス２６とは別に格納し、監督スレッド４４がエグジットするよう合図されたときに実行するために取り出すことが可能である。プロセス状態テーブル７７は、必ずしもクラッシュ検出リカバリモジュール３２に格納する必要はないが、クラッシュ検出リカバリモジュール３２およびイベントハンドラ３４がアクセス可能なメモリ１４の別の場所に格納する必要がある。ルール４１、７０は、通常、プロセス２６とは別々に格納されるが、ある特定のプロセス２６に適用可能なルールはルールを覆い隠すという生じ得る不利な点はあるが斯かるプロセス内または関連する監督スレッド４４内に格納することができる。プロセス制御モジュール３０、イベントハンドラ３４、およびクラッシュ検出リカバリモジュール３２は、本発明の範囲を逸脱することなくそれらの機能に基づいて、より大きなコードセグメントに組み合わされる、またはより小さなコードセグメントに分割されることが可能である。これらの変更および他の変更は、当業者であれば本発明の範囲を超えることなく実施することができることは理解されよう。
【００５２】
上述の説明と添付図面に提示された教えの恩恵に浴した当業者であれば本発明の上記実施形態の多くの変更形態と他の実施形態が思い浮かぶことであろう。それゆえに本発明は開示した特定の実施形態には限定されないこと、そして上記実施形態の変更形態と他の実施形態は本願特許請求の範囲内に含まれることが意図されていることは理解されるべきである。本願明細書には特定の用語が使用されているが、それらは限定目的ではなく、総称的で記述的な意味でのみ使用されている。
【産業上の利用可能性】
【００５３】
ここに開示および請求された様々な実施形態のコンピュータおよび媒体はプロセスのクラッシュを自動的に検出およびリカバリすることができるようにすることでコンピュータ分野における産業上の利用可能性を有する。
【図面の簡単な説明】
【００５４】
【図１】１つ以上のプロセスを制御するとともにプロセスのクラッシュから自動的にリカバリするためのモニタプログラムが格納されたメモリ（すなわちコンピュータ可読媒体）を有する本発明の実施形態によるコンピュータのブロック図である。
【図２】プロセス外部の監督スレッドを使用してプロセスを監視制御するとともにプロセスのクラッシュが発生した場合に設定可能なリカバリを実行するためのモニタプログラムによって実行される本発明の実施形態による方法のフロー図である。
【図３】プロセスを開始し、プロセスを制御するために監督スレッドを生成するためのモニタプログラムの開始プログラムによって実行される本発明の実施形態による方法のフロー図である。
【図４】プロセスを停止し、クラッシュ検出リカバリモジュールにプロセスが停止したことを通知するためのモニタプログラムの停止プログラムによって実行される本発明の実施形態による方法のフロー図である。
【図５】停止プログラムがカスタマイズされたエグジット処理を開始するために監督スレッドに停止対象のプロセスを通知する本発明の実施形態による方法のフロー図である。
【図１】
2008546077.tif 000003
【図２】
2008546077.tif 000004
【図３】
2008546077.tif 000005
【図４】
2008546077.tif 000006
【図５】
2008546077.tif 000007
【手続補正書】
【提出日】平成19年7月3日(2007.7.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プロセス制御モジュールおよびクラッシュ検出リカバリモジュールを含むモニタプログラムを格納するメモリと、このメモリに接続されており前記プロセス制御モジュールおよび前記クラッシュ検出リカバリモジュールを実行して所定の機能を実行するよう構成されたプロセッサとを備えるコンピュータであって、
前記プロセス制御モジュールはクライアントプロセスとは別に規定された前記メモリに格納されたルールに基づいてそのクライアントプロセスを開始または停止し、前記プロセス制御モジュールはオペレーティングプラットフォームにクライアントプロセスの開始を要求することによってそのクライアントプロセスを開始し、開始されたクライアントプロセスのためのハンドルをオペレーティングプラットフォームから受信し、第１の監督スレッドを生成してそれを前記ハンドルと共に開始されたクライアントプロセスに組み込み、開始されたクライアントプロセスの実行状態の監視に使用するために前記ハンドルを第１の監督スレッドに付随した形で前記プロセス制御モジュールに格納し、前記プロセス制御モジュールは前記監督スレッドを通じて関連するクライアントプロセスが終了したことを検出したらそれに応えてエグジット通知イベントを生成し、前記プロセス制御モジュールはそのクライアントプロセス内の第２の監督スレッドのプロセス間通信オブジェクトにこのプロセス間通信オブジェクトのハンドルを使用して合図することによってそのクライアントプロセスを停止し、
前記クラッシュ検出リカバリモジュールは開始されたクライアントプロセスの１つ以上のプロセスに対して定められたクラッシュリカバリプランを格納し、前記クラッシュ検出リカバリモジュールはプロセス状態テーブルを管理し、クライアントプロセスが正常に終了した場合には前記プロセス制御モジュールから正常終了信号を受信し、停止したクライアントプロセスからこの停止したプロセスに対応する第１の監督スレッドを通じてこのクライアントプロセスが停止したことを示すエグジット通知信号を受信し、前記クラッシュ検出リカバリモジュールは、前記プロセス制御モジュールから前記エグジット通知信号を受信したらそれに応えて、停止したクライアントプロセスが前記プロセス状態テーブルの中に対応する正常終了データを持っているかどうかをチェックすることによって、そのプロセスの終了が正常であったかどうかを判定し、前記クラッシュ検出リカバリモジュールはコンピュータがクライアントプロセスのクラッシュからどのようにリカバリするかを規定する少なくとも１つのクラッシュリカバリプランを格納し、前記プロセス制御モジュールはクライアントプロセスの終了がクラッシュの結果生じたものであると判定した場合には前記クラッシュリカバリプランを実行することを特徴とするコンピュータ。
【請求項２】
前記メモリは、前記プロセス制御モジュールからクライアントプロセスが終了したことを示すエグジット通知信号を受信し、前記クラッシュ検出リカバリモジュールにそのエグジット通知信号を通知するイベントハンドラを更に格納し、前記クラッシュ検出リカバリモジュールは、前記プロセス制御モジュールからのエグジット通知信号に応えて対応するクライアントプロセスの終了が正常であったかどうかを判定することを特徴とする請求項１に記載のコンピュータ。
【請求項３】
前記プロセス制御モジュールは、ルールが許すときに前記プロセス制御モジュールによって実行される開始リクエストおよび停止リクエストを格納する待ち行列を有することを特徴とする請求項１に記載のコンピュータ。
【請求項４】
前記モニタプログラムはコンピュータを起動する際に実行される開始リクエストおよび停止リクエストが設定された初期化プログラムを更に含み、前記初期化プログラムは設定された開始リクエストおよび停止リクエストをコンピュータを起動する際に実行するために前記待ち行列に入力することを特徴とする請求項３に記載のコンピュータ。
【請求項５】
前記待ち行列に入力された開始リクエストおよび停止リクエストの少なくとも１つは実行中のプロセスを発信源とするものであることを特徴とする請求項１に記載のコンピュータ。
【請求項６】
プロセッサと、
該プロセッサに結合したメモリとを備え、
該メモリは当該コンピュータ上で走るクライアントプロセスのための対応する監督スレッドを有するモニタプログラムを格納し、前記監督スレッドは対応するクライアントプロセスの外部で動作して、前記プロセッサが対応するクライアントプロセスをそのプロセスの外部で監視することを可能にするものであり、前記モニタプログラムは、クライアントプロセスのクラッシュからリカバリするためのプランを規定するクラッシュリカバリプランを格納するクラッシュ検出リカバリモジュールを更に含み、前記プロセッサは前記リカバリプランを実行して当該コンピュータのユーザの関与を要求することなくクライアントプロセスのクラッシュから自動的にリカバリし、前記クラッシュ検出リカバリモジュールは、クライアントプロセスが正常に終了したことを示すために前記モニタプログラムの停止プログラムによってセットされる正常終了フラグデータを格納するプロセス状態テーブルを含むことを特徴とするコンピュータ。
【請求項７】
前記モニタプログラムは、オペレーティングプラットフォーム上で走るクライアントプロセスの開始に応答してそのオペレーティングプラットフォームからのハンドルを使用し、そのクライアントプロセスの監視に使用するために前記監督スレッドをその中に前記ハンドルを含む形で生成する開始プログラムを含むことを特徴とする請求項６に記載のコンピュータ。
【請求項８】
前記開始プログラムはクライアントプロセスが開始できるかどうかを判定するためにこの開始プログラムによって使用される１つ以上のルールを含み、前記開始プログラムはクライアントプロセスが開始できることをそのクライアントプロセスの外部で定められた１つ以上のルールに基づいて決定したらそれに応えてクライアントプロセスの開始に着手することを特徴とする請求項７に記載のコンピュータ。
【請求項９】
当該コンピュータは、入力装置と、出力装置と、インタフェース装置とを更に備え、
前記モニタプログラムは、監督スレッドと、クライアントプロセスに対応するハンドルおよび対応するクライアントプロセス内に保持されるプロセス間通信オブジェクトのハンドルの１つ以上のハンドルを使用してクライアントプロセスを制御するために、前記プロセッサによって実行される別の実行中のプロセス、前記入力装置および前記出力装置を介してユーザ、前記インタフェース装置を介して外部機器、またはそれらの組み合わせによってトリガーすることができる開始プログラム、停止プログラム、またはその両方を含むことを特徴とする請求項６に記載のコンピュータ。
【請求項１０】
前記メモリは、当該コンピュータを起動する際に前記プロセッサによって開始される１つ以上のプロセスから成るプロセス群を規定する初期化プログラムを格納することを特徴とする請求項６に記載のコンピュータ。
【請求項１１】
前記モニタプログラムはクライアントプロセスが終了する際にそのクライアントプロセスの監督スレッドからエグジット通知を受信し、そのクライアントプロセスは正常に終了したのかあるいはクラッシュの結果なのかを判定するために前記クラッシュ検出リカバリモジュールを活動化するイベントハンドラを更に含むことを特徴とする請求項６に記載のコンピュータ。
【請求項１２】
コンピュータによって実行されるときに、
コンピュータのプロセッサ上で走るクライアントプロセスを開始したらそれに応えてそのクライアントプロセスの外部に第１の監督スレッドを、オペレーティングプラットフォームから受信された第１のハンドルをその中に含むように生成する手順と、
第２の監督スレッドを第２のハンドルと共に生成し、それを開始されたクライアントプロセスに組み込むとともに、開始されたクライアントプロセスの実行状態の監視に使用するために第２のハンドルを第２の監督スレッドに付随する形で格納する手順と
を実行するコンピュータプログラムを格納することを特徴とするコンピュータ可読媒体。
【請求項１３】
前記コンピュータプログラムは、コンピュータの起動（ブート）、再起動（リブート）、リスタート、またはそれらの組み合わせに応答して初期化プログラムをプロセッサで実行する手順を更に含み、前記初期化プログラムの実行はこの初期化プログラムによって規定される１つ以上のクライアントプロセスから成るプロセス群を開始することを含み、前記監督スレッドの生成は前記初期化プログラムによって規定された各それぞれのクライアントプロセスごとに実行され、それにより各実行中のクライアントプロセスはプロセッサが各実行中のクライアントプロセスの実行状態を監視するために使用することができる対応する監督スレッドを持つことができることを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１４】
前記コンピュータプログラムはクライアントプロセスを開始するためのリクエストを受信する手順を更に含み、前記監督スレッドの生成はそのリクエストを受信したらそれに応えて実行されることを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項１５】
前記コンピュータプログラムは前記リクエストを受信したらそれに応えて、クライアントプロセスの外部で規定された１つ以上のルールに基づいてそのクライアントプロセスが開始できるかどうかを判定する手順を更に含み、クライアントプロセスの開始はその１つ以上のルールに基づいてそのクライアントプロセスが開始できることが決定されたらそれに応えて実行されることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
前記リクエストは、プロセッサによって実行される別のプロセスから受信されることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記リクエストは、コンピュータの入力装置を介してユーザから受信されることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１８】
前記リクエストは、コンピュータのインタフェース装置を介して外部機器から受信されることを特徴とする請求項１４に記載のコンピュータ可読媒体。
【請求項１９】
前記コンピュータプログラムは、オペレーティングプラットフォームがクライアントプロセスを開始した後に、そのオペレーティングプラットフォームからハンドルを受信する手順を更に含み、そのハンドルの受信は前記監督スレッドが生成される前に実行されることを特徴とする請求項１２に記載のコンピュータ可読媒体。
【請求項２０】
コンピュータによって実行されるときに、コンピュータのプロセッサ上で走るクライアントプロセスを開始したらそれに応えてクライアントプロセスの内部に第１の監督スレッドを生成する手順を実行するコンピュータプログラムを格納し、第１の監督スレッドは、クライアントプロセスに実行の停止を合図するために、そのプロセスをターゲットとするプロセス外部のモニタプログラムからの停止リクエストによって活動化され、前記モニタプログラムは前記停止リクエストを、前記モニタプログラムがターゲットであるクライアントプロセスと通信することを可能にする第２の監督スレッドのプロセス間通信オブジェクトのハンドルを使用して、そのクライアントプロセスに送信することを特徴とするコンピュータ可読媒体。
【請求項２１】
前記プロセス間通信オブジェクトは、セマフォー（ｓｅｍａｐｈｏｒｅ）、ミューテックス（ｍｕｔｅｘ）、イベント（ｅｖｅｎｔ）、またはそれらの組み合わせの中の少なくとも１つから成ることを特徴とする請求項２０に記載のコンピュータ可読媒体。
【請求項２２】
前記コンピュータプログラムは、
前記モニタプログラムにおいてクライアントプロセスを停止するためのリクエストを受信する手順と、
前記リクエストを受信したらそれに応えてクライアントプロセス内のプロセス間通信オブジェクトのハンドルに合図することによって前記モニタプログラムからそのクライアントプロセスを停止する手順と
を更に含むことを特徴とする請求項２０に記載のコンピュータ可読媒体。
【請求項２３】
前記コンピュータプログラムは、
前記リクエストを受信したらそれに応えて、クライアントプロセスの外部で規定された１つ以上のルールに基づいてそのクライアントプロセスが停止できるかどうかを判定する手順を更に含み、
クライアントプロセスの停止は、前記１つ以上のルールに基づいて、そのクライアントプロセスは停止することができると判定されたらそれに応えて実行されることを特徴とする請求項２２に記載のコンピュータ可読媒体。
【請求項２４】
前記リクエストは、プロセッサによって実行される別のプロセスから受信されることを特徴とする請求項２０に記載のコンピュータ可読媒体。
【請求項２５】
前記リクエストは、ユーザからコンピュータの入力装置を介して受信されることを特徴とする請求項２０に記載のコンピュータ可読媒体。
【請求項２６】
前記リクエストは、外部機器からコンピュータのインタフェース装置を介して受信されることを特徴とする請求項２０に記載のコンピュータ可読媒体。
【請求項２７】
プロセッサと、
該プロセッサに結合したメモリとを備え、
該メモリは前記プロセッサによって実行されるクライアントプロセスのためのリカバリプランを規定するクラッシュ検出リカバリモジュールを格納し、前記クラッシュ検出リカバリモジュールは自動的にクライアントプロセスのクラッシュを検出し、当該コンピュータのユーザによるアクションを何も要求することなく前記リカバリプランを実行することによってクライアントプロセスのクラッシュからリカバリするとともにプロセス状態テーブルを管理し、前記プロセス状態テーブルは、クライアントプロセスが正常に終了した場合には正常終了信号を受信し、停止したクライアントプロセスからこのプロセスが停止したことを示すこの停止したプロセスに対応するエグジット通知信号を受信することを特徴とするコンピュータ。
【請求項２８】
前記リカバリプランは、クライアントプロセス別に定められることを特徴とする請求項２７に記載のコンピュータ。
【請求項２９】
前記リカバリプランは、クライアントプロセス別に定められたリカバリプランの中に該当するものが存在しない場合には、クライアントプロセスのクラッシュからリカバリするために使用されるデフォルトプランであることを特徴とする請求項２７に記載のコンピュータ。
【請求項３０】
前記リカバリプランは、コンピュータが再起動（リブート）されるべきであることを示すことを特徴とする請求項２７に記載のコンピュータ。
【請求項３１】
前記リカバリプランは、クライアントプロセスがリスタートされるべきであることを示すことを特徴とする請求項２７に記載のコンピュータ。
【請求項３２】
前記リカバリプランは、前記プロセッサが少なくとも１つの他のクライアントプロセスを停止すべきであることを示すことを特徴とする請求項２７に記載のコンピュータ。
【請求項３３】
前記リカバリプランは、前記プロセッサが少なくとも１つの他のクライアントプロセスを開始すべきであることを示すことを特徴とする請求項２７に記載のコンピュータ。
【請求項３４】
コンピュータによって実行されるときに、
コンピュータのプロセッサ上で走るクライアントプロセスのクラッシュをこのクライアントプロセスの外部で検出する手順であって、
監督スレッドが、停止したクライアントプロセスのハンドルの無効化を通じて合図されたらそれに応えて、エグジット通知イベントを生成することと、
前記エグジット通知イベントを受信することと、
クライアントプロセスの正常終了フラグがそのクライアントプロセスによって終了前にセットされていることをチェックすることと、
クライアントプロセスがクラッシュしたことを前記チェックに基づいて決定することと、
前記クラッシュリカバリプランが前記決定に基づいて実行されることを含む、検出する手順と、
自動的にクラッシュリカバリプランを実行してクライアントプロセスのクラッシュからリカバリする手順と
を実行するコンピュータプログラムを格納することを特徴とするコンピュータ可読媒体。
【請求項３５】
前記クラッシュリカバリプランは、クライアントプロセス別に定められることを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項３６】
前記クラッシュリカバリプランは、クライアントプロセス別に定められたリカバリプランの中に該当するものが存在しない場合には、クライアントプロセスのクラッシュからリカバリするために使用されるデフォルトプランであることを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項３７】
前記クラッシュリカバリプランは、プロセッサにコンピュータの再起動（リブート）を指示することを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項３８】
前記クラッシュリカバリプランは、プロセッサにクラッシュしたクライアントプロセスのリスタートを指示することを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項３９】
前記クラッシュリカバリプランは、プロセッサに少なくとも１つの追加のプロセスの開始を指示することを特徴とする請求項３４に記載のコンピュータ可読媒体。
【請求項４０】
前記クラッシュリカバリプランは、プロセッサに少なくとも１つの追加のプロセスの停止を指示することを特徴とする請求項３４に記載のコンピュータ可読媒体。
【国際調査報告】
2008546077.tif 000008
2008546077.tif 000009
2008546077.tif 000010