問題タブ [waitformultipleobjects]

私はプロセスマネージャーを持っています。createprocess 関数を使用して、何千もの (紙の上で!) 子プロセスを作成する可能性があります。現在、子の終了または失敗を検出するために、マルチスレッドと WiatForMultipleObejct を使用しています。可能であれば、IOCP

を使用して子プロセスの終了を検出するためのアドバイス/ガイドライン/疑似コード/リンクを探していました!?

どうもありがとう！

WaitForSingleObject() または WaitForMultipleObjects() が、待機しているオブジェクトが CreateEvent() で作成されたイベントである場合に ERROR_IO_PENDING を返す理由を知っている人はいますか?

テストでは、WFSO と WFMO、手動と自動、INFINITE と 5000 を試しましたが、WaitFor* を呼び出すとすぐに ERROR_IO_PENDING が返されます。

イベントオブジェクトについて、一体何が保留中になる可能性があるのでしょうか? それらのポイントは、あなたがそれらを待つことです。このイベントは OVERLAPPED の一部ではなく、IO 呼び出しとは関係ありません。ワーカースレッドが終了するためのワンショットフラグとして使用されているだけです（これは別のスレッドによって SetEvent() されます）。

それで - 質問は - WFSO から戻ってきた ERROR_IO_PENDING - そしてアイデアですか?

リッチ

.dmp ファイルで debugdiag 1.2 を使用しています。私はマイクロソフトのサポートと協力しており、さまざまな関数トレースの詳細を取得しています。彼のバージョンは、関数名とパラメーターがはるかに冗長です。

彼と同じものを手に入れるのに何か欠けているものがあるのだろうか？

たとえば、次のようになります。

同じダンプ ファイルの場合、次のようになります。

DebugDiag は非常に便利なツールのように見えます。これについて十分に理解したいと思います。お時間をいただきありがとうございます。

関数を使用WaitForMultipleObjects(... /*bWaitAll=*/FALSE ...)すると、最初の同期オブジェクトの状態が明らかに変更され、それが返されます。つまり、通知された自動リセットイベントがあり (持っていた) 、戻り値がこのイベント オブジェクトによって関数が返されたことを示している場合、確実にリセットされたことになります。

ただし、複数のオブジェクトがある場合を考えてみましょう- ここに:

bWaitAllisの場合FALSE、この関数は、オブジェクトの 1 つが通知されるまで、インデックス 0 から順に配列内のハンドルをチェックします。 複数のオブジェクトがシグナル状態になった場合、関数はオブジェクトがシグナル状態になった配列内の最初のハンドルのインデックスを返します。

したがって、最初のハンドルのみが返され、このインデックスの後にイベントが通知されたかどうかはわかりません。

状態が変更されたオブジェクトの場合、問題は、WaitForMultipleObjects が返されたときに複数のオブジェクトが通知されていた場合、最初のオブジェクトの状態のみが変更されるのか、それとも通知されたすべてのオブジェクトがリセットされるのかということです。

ドキュメントには次のように記載されています。

この関数は、一部のタイプの同期オブジェクトの状態を変更します。変更は、シグナル状態によって関数が返されたオブジェクト(複数可)に対してのみ発生します。

したがって、これは、複数のオブジェクトの状態が実際に変更される可能性があることを示しています。ただし、これは次のステートメントと少し矛盾しています。

... この関数は、オブジェクトの 1 つが通知されるまで、インデックス 0 から順番に配列内のハンドルをチェックします。...

さらに、常に情報が失われるため、状態が変更された複数の同期オブジェクト (自動リセット イベント、セマフォなど) でこの関数を使用することは不可能であることを意味します。

「複数のハンドルがある場合の WaitForMultipleObjects の動作...」に対するこの回答で、他の人がそれを結論付けるステートメントを見つけました(そこのコメントから):

WaitForMultipleObjects() はハンドル配列を 0 からスキャンし、シグナルされたハンドルを見つけるとすぐに戻ります。最初に見つかったハンドルのみが非シグナル状態にリセットされます。他はそのままです。— user82238 / 09 年 3 月 25 日 19:27 に

しかし、これを明示的に再質問し、おそらく確認したいと思います。

CodeGuruにも興味深い議論がありますが、これには何の光も当てていないようです。

複数のスレッドを持つ MFC コードがあり、それらすべてが異なるパラメーターを使用してサブルーチンを再帰的に呼び出します。サブルーチンの最初で、関数 CheckKillEvent() を呼び出します。

CheckKillEvent が true を返した場合、return() はすぐに返されます。

fyi、h_killEvent は次のように初期化されます。

つまり、手動リセットがあります。

ただし、これらのスレッドは、次のように Kill イベントを設定した後、(文字通り) 永遠に終了するようです。

問題は、複数のスレッドから CheckKillEvent() を呼び出すことに問題があるかどうかです。WaitForSingleObject() はクリティカル セクション内で実行する必要がありますか? それとも、再帰コードが自分自身を呼び出さなくなった時点まで再帰するのが苦手なだけですか?

このスレッドで、プログラムが ShellExecuteEx を待機するようにするコードを既に見つけました。ShellExecuteEx で複数のファイルを開始し、すべてのファイルが閉じられるまで待機するにはどうすればよいですか?

待機するコードは次のとおりです。

同時に 3 つのスレッドを実行し、メイン スレッドでどのスレッドが終了したかを検出しようとしています。WaitForMultipleObject 関数を使用していますが、3 番目のスレッドがこの WFMO 関数に対してループしているように見えますが、ジョブは既に終了しています (印刷された結果)。

出力：