日々の破片

_ アプリケーション死すともプロセス死せず

CPUが早くなって、しかもコア数が増えて同時実行可能なプロセス数が増えると、考えもしないタイミングが生まれる。

GetExitCodeProcess APIは、"If the process has terminated and the function succeeds, the termination status returned may be one of the following"だから、プロセスは現在完了形でターミネートしていて、呼び出しに成功したらステータスが返る。ということはプロセスはターミネートしているはずだ。

でも、どうもそうではない。というのは、ロジカルに特定のプロセスがCDしているディレクトリが、そのプロセスがターミネートした（追記：と、上のようにGetExitCodeProcess呼び出しの結果から判断した）にもかかわらずアクセス中のプロセスが存在して消せないという状態になることがあるからだ。

ExitProcess APIの説明を読むと、Exiting a process causes the following:として、

1. プロセスがオープンしたすべてのオブジェクトハンドルをクローズする

2. 呼び出したスレッド意外のすべてのプロセス内のスレッドの実行がターミネートする。 DLLのDLL_PROCESS_DETACHを呼び出す。

3. プロセスオブジェクトはシグナル状態になる。

4. すべてのスレッドがシグナル状態になる。

5. プロセス状態はSTILL_ACTIVEから終了値に変わる

と書いてあるから、プロセスハンドルがシグナルになるのは3でGetExitCodeProcess呼び出しより前に思える。だが、この数字は単なるドットの意味しかないとしたらどうだろうか？

Terminating a Processの章には次の記述がある。

"When a process terminates, its termination status changes from STILL_ACTIVE to the exit code of the process.

When a process terminates, the state of the process object becomes signaled, releasing any threads that had been waiting for the process to terminate. For more about synchronization, see Synchronizing Execution of Multiple Threads."

この順で処理されるとしたら、まず終了ステータスがSTILL_ACTIVEから退出コードに変更される。次に、プロセスオブジェクトがシグナル状態になる。

CPUが高速で、同時に実行できるプロセスが2つ以上あれば、上記の文章がその順序に発生するとしたら、ちょうど改行の位置でGetExitCodeProcessを呼び出すことが可能だ。

これは結構おそろしい。つまり、他のプロセス（や他のスレッド）に対して自分の状態変化を複数の状態変数を通して教える場合、その順序は厳密に文書化しなければならないし（したがって、MSDNのTerminating a Process（多分正しい順序)と、ExitProcess（多分正しくない順序）のように矛盾があってはならない）、逆に教えられる側は、その順序を守るか、さもなければすべての状態変数の確認をしなければならないということだ。

大変な時代に突入したものだ。

追記：コメント欄のNyaRuRuさんの他のプロセスの介入の可能性という指摘は確かにあるので(今回の僕のケースだとちょっと考えにくいけど)、可能性いろいろということで。（すると結論は、ソースが読めないOSでは、微妙なタイミングの処理を正しく記述することは不可能というような方向になったりするのかも知れない）