4

私は現在、IO完了ポートを使用する名前付きパイプに基づくIPCメカニズムに取り組んでいます。

残念ながら、msdnのドキュメントに問題があります。これは、ReadFile / WriteFileを呼び出すと、完了パケットが生成されるかどうかがはっきりしないためです。

ERROR_IO_PENDINGでFALSEが返される場合は明らかですが、ERROR_MORE_DATAが返される場合の明らかに可能な場合はどうでしょうか。この場合、完了パケットはありますか？さらに、他のエラーが返された場合はどうなりますか？どの場合、完了ハンドラーではなく、結果を処理してリソースを直接解放する必要がありますか？

もう1つのケースは、ReadFile / WriteFileが成功した場合ですが、これも可能です。ありがたいことに、MSDNはこれについてかなり明確です：

さらに、WriteFile関数は、非同期ハンドルを使用している場合でも、GetLastError値がERROR_SUCCESSの場合にTRUEを返すことがあります（ERROR_IO_PENDINGの場合はFALSEを返すこともあります）。...この例では、完了ポートルーチンがそのようなリソースのすべての解放操作に対して単独で責任を負うことを許可することをお勧めします。

この推奨事項はすべての場合に正しいのでしょうか。また、完了ポートに割り当てられたハンドルに対するReadFile / WriteFile操作の結果は、パケットがポートに送信されるため、実際には完全に無視できますか（実際には無視する必要があります）。

4

2 に答える 2

3

IO操作を開始できるときはいつでも、IO操作のためにキューに入れられたIO完了項目があります。IO操作の開始後にエラーが発生したかどうかに関係なく、完了項目は完了ポートにキューに入れられます。

IOシステムによって返されるコードとWin32エラーコードの間にマッピングの問題があり、NTSTATUSどのステータスがエラーであり、どのステータスが単なる情報であるかを判断するのが困難です。NTSTATUS、カーネルとネイティブAPIで使用される、重大度には、成功、情報、警告、エラーの4つのレベルがあります。エラーコード以外は、IO操作を開始できたことを示します。Win32には重大度（ERROR_*）が1つしかないため、成功、情報、および警告コードをエラーコードと一緒にマップする必要がありました。

  • ERROR_IO_PENDING-STATUS_PENDING成功ステータスです
  • ERROR_MORE_DATA-STATUS_BUFFER_OVERFLOW警告またはSTATUS_MORE_ENTRIES成功ステータス

ReadFileまたはWriteFileが返すエラー以外のコードを無視して、キューに入れられた完了項目を期待することはできますが、どちらが少し面倒な場合があるかを判断できます。Win32エラーコードがより適切に整理されていればいいのですが、MicrosoftはNTSTATUSWin32エラーコードへのマッピングを提供しています：http ：//support.microsoft.com/kb/113996 。ntstatus.hプラットフォームSDKまたはVSインストールを参照して、NTSTATUSコードの重大度を判別してください。

元のAPI呼び出しが戻ったときに、IO操作が完了する可能性があります。たとえば、キャッシュからコピーされたばかりの読み取り要求（非同期で待機するものはありません）。このような場合でも、一貫性を保つために、完了メッセージはキューに入れられます。

于 2011-03-31T13:28:29.107 に答える
1

  • はい、ERROR_MORE_DATA完了パケットで発生する可能性は完全にあります。潜在的なエラーを処理する準備を常に整えておく必要があります。のドキュメントでは、が返されるときに、パラメータがであるかどうかを確認する必要がGetQueuedCompletionStatusあることは明らかです。そうでない場合、I/O完了パケットにはエラーが含まれています。FALSElpOverlappedNULLNULL

  • ReadFileデフォルトの動作では、またはWriteFileが戻った場合でも、完了パケットは完了ポートまでキューに入れられTRUEます。Windows Vista以降、このポリシーは変更できます。のドキュメントを参照してくださいSetFileCompletionNotificationModes。

于 2011-03-31T16:57:48.207 に答える