関数ソケットclose()メソッドの戻り値が「-1」である可能性はありますか?

関数ソケットclose()メソッドの戻り値が「-1」である可能性はありますか?

close(int fildesc)メソッドを使用してネットワークソケットを閉じると、どのような状況で戻り値-1を生成できますか?間違ったfildesc番号を使用することは可能であると思いますが、既存の有効なソケットを使用するとこれが起こりますか?

このような場合、プログラムはどのように反応する必要がありますか?

ベストアンサー1

Linuxのマニュアルページclose()有効なファイル記述子から-1を返すことができるいくつかのケースについて説明します。

close()の戻り値をチェックしないのは一般的ですが、深刻なプログラミングエラーです。前の write(2) ジョブのエラーが最後の close() で最初に報告される可能性が高いです。ファイルを閉じるときに戻り値を確認しないと、自動的にデータが失われる可能性があります。これは、特にNFSとディスククォータで観察されます。

この部分はLinux以外のカーネルにも当てはまると思います。そして次のような警告があります(強調)。

戻り値は診断にのみ使用できます。 特にEINTRの後にclose()を再試行しないでください。これは、他のスレッドで再利用された記述子を閉じることができるためです。

以下の基本原則のいくつかを読んでください。このlwn.netの記事:

close() に渡されたファイル記述子は、システムコール処理の最初に割り当て解除され、close() が返されると、同じ記述子が別のスレッドに配布された可能性があります。

したがって、ソケット記述子の場合、EINTRソケットを閉じるとき、特にソケットを使用して大量のデータを送信した後に発生する可能性がありますいいえLinuxでは、次のコードを書いています。

while (close(sock) == -1 && errno == EINTR);

おすすめ記事