fork()プロセスの場合、子プロセスはファイル記述子を継承します。問題はなぜですか？
私がビューにファイル記述子を共有することは、各プロセスがr / wポインタの位置を追跡しようとしたときに面倒です。
このデザイン決定がなされたのはなぜですか？
答え1
シェルの断片を考えてみましょう。
{ somecmd; othercommand *.txt; } > outputfile
リダイレクトが開始されると、シェルはoutputfile一度開き、ファイルハンドルをに渡して処理somecmdします。グループ化を考慮すると、ユーザーは両方のコマンドの出力が終了することを期待します。これはおそらく画面に表示されるのと同じように正しいでしょう。 （グループがシェルスクリプトの場合でも、状況は同じです。）othercmdforkoutputfile{ }
ファイルの場所がすべてのプロセスに対して独立している場合、出力はothercommand破損しますsomecmd。ファイルハンドルの位置がリセットされると、シェルはエンドを指すハンドルを渡すことforkができません（ファイルハンドルがファイルハンドルの後ろにあるため）。パイプを使用して2つのコマンドの出力を収集し（とにかく位置に依存しない）、他のプログラムから2つのコマンドの出力を接続する必要があります。othercommandoutputfilesomecmd
{ somecmd; othercommand *.txt } | cat > outputfile
答え2
POSIXこれは推論を説明します:
POSIXプログラマが呼び出すには2つの理由があります。クロス()。 1つの理由は、同じプログラム内に新しい制御スレッドを作成することです（これは元のPOSIXで新しいプロセスを作成することによってのみ可能でした）。もう一つの理由は、別のプログラムを実行する新しいプロセスを作成することです。後者の場合、電話クロス()すぐに電話に出ます。実装する機能。
「貧しい人々のスレッド」として使用される場合は、ファイル記述子をコピーすることをお勧めfork()します。このユースケースは引き続きサポートされる必要があるため、機能はそのまま残ります。