2009-03-24 8 views
0

UDPソケットでIOCPを使用していて、UDPソケットが別のスレッドで閉じられている可能性があります。では、SOCKETに関連するPer I/O ContextとPer I/O Contextを安全にどのように解放することができますか?I/O完了ポート、ソケットコンテキストごとおよびI/Oコンテキストごとの解放方法

ソケットを閉じると、未完了のI/O要求がカーネルキューに残ります。

ソケットを閉じたときにコンテキストを解放すると、GetQueueCompletionStatusが失敗することがあります。

私の質問は文脈を自由にするときです。

答えて

1

mutexを使用して、コードの重要な部分に相互排除を強制します。これにより、ソケットの可用性がチェックされ、必要に応じて開きます。そのソケットにソケットをロックし、完了したらソケットを適切に解放します。

3

ソケットとI/Oデータ構造ごとに参照カウントを使用します。このようなことは、参照が0になったときに削除されるので簡単になります。これを行う方法の1つを示すコード例では、無料のIOCPフレームワークをご覧になれます。hereからダウンロードできます。

0

ソケットごとの構造を再利用します。その接続に必要なすべての読み書き操作の完了イベントを受け取った後、私はTF_DISCONNECTTF_REUSE_SOCKETフラグを付けてTransmitFileと呼び出して、ソケットを閉じることなくソケットをリセットします。 TransmitFileコールの完了イベントが完了すると、接続ごとのデータもリセットされます。

0

最初にソケットを閉じます。 GetQueuedCompletionStatusからエラー(私はそれがERROR_OPERATION_ABORTEDだと思います)を取得し、構造を解放するのが適切な時です。それまでにカーネルキュー内でこの接続に未完了の要求はなく、完了パケットはFIFO順に維持され、エラーパケットは間違いなくこの接続の最後のパケットになります。

+0

保留中のパケットは何ですか?例えば読み取りと書き込みが保留中の場合は、最初にERROR_OPERATION_ABORTEDを返すかどうかわかりません。 –

+0

有効な完了キーとGetQueuedCompletionStatus()から返された重複したパラメータは、ERROR_OPERATION_ABORTEDを指定しても取得されます。あなたは自由にしたい文脈にどちらかを使うかもしれません。 –

+0

私が書いたものと読んだものの両方がある場合(つまり、2つのオーバーラップされた構造がI/O完了を待っている)、どちらが最初に完了するかわからず、最後に完了するでしょう両方ともERROR_OPERATION_ABORTEDを返しても)、最後に完了する*アトミックカウンタを必要とします。その後、そこからクリーンアップルーチンを呼び出してメモリを解放します。 –

関連する問題