私はReadDirectoryChangesW()のドキュメントを読んでいて、CDirectoryChangeWatcher projectも見ていますが、どちらもと言うわけではありません。なぜなら、は非同期的に呼びたいと思っています。 現在のスレッドはブロックされませんが、完了ポートを使用するCDirectoryChangeWatcherコードでは、少なくともGetQueuedCompletionStatus()、、スレッドブロック（変更がない場合）が呼び出されます。なぜReadDirectoryChangesWを非同期で使用するのですか？
ReadDirectoryChangesW()を私が最初にブロックすると気にしない別のスレッドで同期的に呼び出すと、ReadDirectoryChangesW()を非同期に呼び出す必要があるのはなぜですか？
非同期に呼び出すと、より多くの制御があり、スレッドが待機します。また、ディレクトリ変更、イベント、メッセージなど、複数のものが1つのスレッドで待機するようにすることもできます。最後に、最初の場所で時計を設定する同じスレッドで待機を行っている場合でも、待機する時間の長さを制御できます。 GetQueuedCompletionStatusには、ReadDirectoryChangesWが単独で提供していないタイムアウトパラメータがあります。
呼び出しスレッドをブロックしないようにする必要がある場合は、結果を非同期的に返すようにReadDirectoryChangesWを呼び出します。トートロジー、しかし真実。
このようなスレッドの候補：UIスレッド&多くのリソース（ソケット、あらゆる種類のIPC、独立したファイルなど）のサービスに専念するスレッド。
プロジェクトに慣れていないので、CDirectoryChangeWatcherはワーカースレッドがブロックするかどうか気にしません。一般的に、それはワーカースレッドの性質です。
ワーカースレッドでReadDirectoryChangesを同期して使用しようとしましたが、プログラムの終了時にスレッドが単独で終了しないようにブロックされていました。 TerminateThreadのような悪質なものを使用したくない場合は、非同期呼び出しを使用する必要があります。
スレッドが停止しなかった場合、OSにプロセスが完了したことを伝えていませんでした。 'ExitProcess'はすべてのスレッドを終了します。 MSDNから –
： 「プロセスが終了される方法： 次のいずれかのイベントが発生するまでのプロセスが実行されます。 - プロセスのいずれかのスレッドがのExitProcess関数を呼び出す ... をそのスレッドない限り、プロセスを終了しないでください。スレッドがカーネルオブジェクトを待機している場合、待機が完了するまでスレッドは終了せず、アプリケーションがハングする可能性があります。 –
いい理由はないと言っていますか？私が最初に言ったように、現在のスレッドがブロックするかどうか気にするならば、ブロックするかどうか気にしない別のスレッドを作成します。 –
スレッドの作成は必ずしも良い（良い）選択肢ではなく、APIはできるだけ多くのユーザーを試してサービスするため、asyncオプションを使用します。 –