handleの概念について

Question

windowsのハンドルについて認識があいまいなので確認させてください。

アプリケーションAを開くときにアプリケーションAからハンドルを
取得し、アプリケーションAを閉じるとアプリケーションAにハンドルを
返却すると認識しています。
（そのためアプリケーション自身は自分が使われているかが分かる）

そのためたまにアプリケーションを閉じるときハンドルを返却し忘れると（ハンドルリーク）
アプリケーションはハンドルを貸し出したままだから、使用中のメッセージ
を出してアプリケーションを閉じれないという認識でいますが正しいでしょうか。

何かわかりやすい例があれば教えてください。

Answer 1

まず一般的にハンドルというのは「何らかのリソースを識別・操作するための識別子」の総称であり、windowsにおけるハンドルと言っても、様々な種類・仕組みのハンドルが存在します。

例えば「Windows OS のカーネルが提供するハンドル」「Cのランタイムが提供するハンドル」「特定のサービスやランタイムが提供するハンドル」等々で、タスクマネージャーのプロセス詳細などで表示できるハンドル数は、各プロセスが使用中の「Windows OS のカーネルが提供するハンドル」数になります。

で、ご質問の

アプリケーションAを開くときにアプリケーションAからハンドルを
取得し、アプリケーションAを閉じるとアプリケーションAにハンドルを
返却すると認識しています。

が、どの類のハンドルを想像されて話されているのか今一分からないのですが、「アプリケーションAを開く」＝「プロセスを起動する」という前提の元で説明して行きたいと思います。

まず、最初に述べたように「ハンドル」＝「何らかのリソース」と考え、登場するプログラムを「何らかのリソースを提供するプログラム」と「提供された何らかのリソースを使用するプログラム」に分けて考えます。

質問の例の「アプリケーション」の場合、現在のWindowsで一番近いのは「Windows OS のカーネル」が提供する「プロセスのリソース」になり（正確ではなく、あくまでも概念的ですが）、あるプログラムが新規プロセスを起動を指示すると、「OSのカーネル」が「プロセスのリソース」を作成し、新規プロセスの起動を指示元に、その「プロセスのリソース」の参照用のプロセスハンドルを返します。

なので、「アプリケーションAからハンドルを取得し」ではなく、「プロセス起動に伴い、OSからプロセスハンドルが提供される」が正しい認識となります。

ただし、プロセスハンドルがOSから提供されるかどうかはプロセス起動に用いるAPIの種類によります。また、プロセスハンドルが返されるAPIを使用したとしても、このプロセスハンドルを解放(CloseHandle)しても、「プロセスのリソース」は即時解放されません。

それはOSカーネル自体も、同じ「新規プロセスのリソース」に対するハンドルを確保しているためで、OSはその新規プログラム（プロセス）が終了しない限りハンドルは解放せず、同じリソースを参照している全てのハンドルが解放されない限り、リソース本体は解放されれないためです。

よって、「アプリケーションAを閉じるとアプリケーションAにハンドルを返却する」の部分は、「アプリケーションAを閉じると、OSが内部で確保しているプロセスハンドルを開放する」となります。

（この時、プロセス起動を指示したプログラムが、新規プロセスのハンドルを閉じないまま放置・動作し続けていると、プロセス自体の動作は終了しているけど「プロセスのリソース」は解放されずに、OS内部のプロセス一覧には、そのハンドルが閉じられるまで残り続ける状態になります）

このように、ハンドルという概念を考える時は、「１つの同じリソースを参照する、複数のハンドル」という事も考える必要があり、参照している全ハンドルを閉じる事が重要になります。

そのためたまにアプリケーションを閉じるときハンドルを返却し忘れると（ハンドルリーク）
アプリケーションはハンドルを貸し出したままだから、使用中のメッセージ
を出してアプリケーションを閉じれないという認識でいますが正しいでしょうか。

次にこの部分につていですが、
「ハンドルを返却し忘れると（ハンドルリーク）アプリケーションはハンドルを貸し出したままだから」
の部分は一般的なハンドル全般に対して正しいですが、
「使用中のメッセージ を出してアプリケーションを閉じれない」
の部分は、使用しているハンドル（を提供しているプログラム）の種類、実装による話になります。

ハンドルリーク状態でプログラムを終了しても、「その異常状態を検出して警告を出し、処理を中断する」というのは、一般的では無い仕様と言えます。

例えば、「Windows OS のカーネルが提供するハンドル」「Cのランタイムが提供するハンドル」などは、プロセスの管理情報と結びついて管理されたリソースだったり、プロセスの固有のメモリ空間に閉じたリソースなので、確保したハンドルを明示的に解放しない状態でプログラムが終了しも、OSのカーネルがプロセスのリソースの解放処理の中で、それらの未開放のハンドルも自動的に解放する機能があり、該当プロセスが終了すればリソースリークにはならないからです。

これは、プログラムが例外発生などで異常終了したとして、OSとしてリソースリークを発生させないための処置で、現代のOSの一般的な機能といます。

ただしこの事は、世の中すべてのハンドル（リソース）に通用するわけでは、当然ありません。
最初に述べた「特定のサービスやランタイムが提供するハンドル」や「自前のプログラムが、他のプログラムに影響する独自実装のリソースハンドル」だった場合、キチンとハンドル解放しないでプロセス終了したら、リソースリークになる場合も当然あります。

---

以上、長々と書きましたが、さらに具体的な内容を知りたい場合は、まずは、もう少し具体的なハンドルの種類を明示するとよいと思います。

ちなみに「Windows OS のカーネルが提供するハンドル」については、少し難しいかもしれませんが、Windows OSの内部解説書「インサイドMicrosoft Windows」を読むと色々と分かると思います。

古いバージョンですが、以下のサイトで一部の内容を参照できます。
■カーネルオブジェクト
インサイドMicrosoft Windows 第4版 上

Comments

[mats]

ハンドルごとに動作が違う事は知りませんでした。
ファイルハンドルとプロセスハンドルくらいしか意識しておらず、
どれも同じかと思っておりました。
とても勉強になりました！

[KenjiToriumi]

Win32(64)API が返す、ファイルハンドル、プロセスハンドル、ミューテックスなどは全て「Windows OS のカーネルが提供するハンドル」の分類になるので、たとえ解放忘れがあっても、プロセス終了時にOSが自動的に開放してくれます。
(ミューテックスなら所有権も自動で解放されます）

一般的なプログラムが使用するハンドルはほとんどがこの分類になる事が多いのでので、基本的には「ハンドルは開放を忘れても、プロセス終了時に自動解放される」の認識でよいのですが、最初に書いたように「ハンドル＝Windows OS のカーネルが提供するハンドル」という絶対的な決まりも無いですし、基本的にはOSの自動解放に頼っては絶対ダメなので（何もできない異常終了時以外）、一般的なハンドルの話も記載さていただきました。

自作ドライバーで独自実装ハンドルをユーザープログラムに提供しているケースで、プロセスが異常終了したらハンドルリークしてしまうなんて事例も実際見たことがありますし。

以上、ご参考までに

Answer 2

ハンドルはあくまでもリソースなどに割り当てられた番号なので、返却するという概念はないんじゃないかと思います。
例えば、アプリＡがアプリＢから返却されたハンドルを使って処理し、アプリＡが終了するときには、そのハンドルを指定してアプリＢにリソースの解放を要求する、とかはあると思います。
これを忘れるとメモリリークにつながるのでは。
但しそれはあくまでもアプリの作りによります。
アプリが終了するときに自身が管理しているリソースを自動で解放するのもあるでしょうし。

Answer 3

こんにちは。

何かのリソースを管理しているプログラムから当該リソースを操作するために受け取る値のことをハンドルと呼ぶことが多いです。このハンドルを使って当該リソースを操作します。(リソース管理テーブルのインデックス番号をハンドルとする実装もよく見かけます。)

アプリケーションソフトウェアがハンドルを他のプロセスへ貸し出すケースは少ないと思います。
他のプロセスに対して何らかの機能を提供するプロセスはアプリではなくサービスであることが多いです。

ところで、そもそもWindowsにアプリケーションのハンドルは無かったと思います。
そして、プロセスを終了する際、OSから借りているリソースは大抵の場合自動的に開放されます。OSはプロセスへ貸し出しているリソースを把握していますし、プロセスの終了も把握できるので自動的に開放できます。

リソースの開放を忘れたまま、プロセスが実行継続している状態をリソース・リークといいます。典型的にはメモリ・リークですね。ハンドル・リークとはあまり言わないと思います。ハンドルは単なる識別番号なのでそもそも開放(返却)が不要なケースもそこそこあります。