プロセス1とプロセス2があるとします。どちらも整数4に対応するファイル記述子を持っています。
ただし、各プロセスでファイル記述子4は、カーネルのOpen File Table内のまったく異なるファイルを指しています。
そんなことがあるものか?ファイル記述子は、Open File Tableのレコードへのインデックスになるはずではありませんか?
ファイル記述子、つまり4
は、例では、プロセス固有のファイル記述子テーブルへのインデックスですnot開いているファイルテーブル。ファイル記述子エントリ自体には、カーネルのグローバルオープンファイルテーブルのエントリへのインデックスと、ファイル記述子フラグが含まれます。
各プロセスには、独自のファイル記述子テーブルがあります。プロセス1234のファイル記述子4は、プロセス1234のテーブル内を指しています。プロセス5678のファイル記述子4は、プロセス5678のテーブル内を指しています。よく知っている必要があるのは、ファイル記述子0、1、2です。これらは、各プロセスの標準入力、標準出力、および標準エラーであり、リダイレクト先を示します。
プロセスは同じファイルを複数回開くことができます。これは、たとえば、プロセスの標準出力と標準エラーが同じ端末または同じファイルにリダイレクトされる場合などに、偶然に発生する可能性があります。基になるファイルテーブルエントリ(例 Linux's struct file
)ファイルに関する情報だけではありません。また、オープンモード(読み取りや書き込みなど)やその他の状態(フラグ、close-on-execなど)も含まれます。たとえば、プロセスは、ファイル記述子0のみを読み取るために開かれた端末と、ファイル記述子2のみを書き込むために開かれた端末を持っている場合があります。ファイルテーブルエントリには、ファイル内のプロセスの位置も含まれます。プロセスは、同じファイル内の2つの異なる位置にlseek
したい場合があるため、dup
を使用して、そのファイルへの2つのハンドルを取得します。
各プロセスには、独自のファイル記述子テーブルがあります。それで全部です。
深く学びたい場合は、Richard Stevensによる NIX Network Programming にすべてが詳しく説明されています。
余分なレベルの間接参照で問題が解決しませんか? (「コンピュータプログラミングのすべての問題は、間接レベルを上げることで解決できます」-一部の賢明な灰色のひげ)。つまり、各プロセスの小さな整数は、「Open File Table」へのカーネルスペースインデックスのプロセスごとの配列へのインデックスになります。