プロセスを分岐すると、子プロセスは親プロセスのファイル記述子を継承します。私が知る限り、これが起こると、子プロセスは、同じ開かれたファイル記述を指す各ファイル記述子テーブルへのポインタと共に、親プロセスのファイル記述子テーブルのコピーを受け取ります。これは、次のファイルテーブルと同じですか?http://en.wikipedia.org/wiki/File_descriptor、または他のものか。
答え1
ファイル記述子→オープンファイルの説明→ディレクトリエントリ
dup
open
cp
プロセスで開かれたファイルからファイルの内容まで、複数レベルの間接参照があります。実装面では、これらのレベルは通常、次のレベルを指すカーネルのデータ構造に変換されます。簡単な実装について説明します。実際の実装はより複雑になる可能性があります。
プロセスで開かれたファイルは、負の非整数のファイル記述子によって指定されます。数字0、1、2は一般的な意味を持ちます。プロセスは0(標準入力)から一般入力を読み、1(標準出力)に一般出力を書き、2(標準エラー)にエラーメッセージを書き込む必要があります。これは単なる慣例です。カーネルは気にしません。カーネルは、各プロセスに対して開かれたファイル記述子テーブルを保持することによって、これらの小さな整数をファイル記述子構造。 Linuxカーネルでは、この構造は次のとおりです。struct fd
。
ファイル記述子構造には、以下を指すポインターが含まれています。ファイル説明を開く。プロセス呼び出しなど、複数のプロセスで同じオープンファイル記述を指す複数のファイル記述子があります。dup
友人と一緒にまたはプロセスフォークの後。ファイル記述子(他のプロセスでも)がopen
同じ元の(または同様の)システムコールによって発生した場合は、同じオープンファイル記述を共有します。開かれたファイルの説明には、モード(読み取り専用と読み取り/書き込み、追加など)、ファイル内の場所などを含む、ファイルの開き方に関する情報が含まれます。 Linuxで開かれたファイル記述構造は次のとおりです。struct file
。
開かれたファイル記述はファイルAPIレベルにあります。次のレベルはファイルシステムAPI違いは、ファイルAPIが匿名パイプやソケットなど、ファイルシステムツリーに存在しないファイルを扱うことです。ファイルがディレクトリツリーのファイルの場合、開かれたファイルの説明には、次を指すポインタが含まれます。ディレクトリエントリ。同じファイルをopen
複数回編集する場合は、同じディレクトリエントリを指す複数の開いているファイルの説明があります。ディレクトリエントリには、親ディレクトリへのポインタ、ファイルの場所に関する情報など、ファイルの内容に関する情報が含まれます。 Linuxカーネルでは、ディレクトリエントリは2つのレベルに分けられます。struct inode
ファイルメタデータを含むstruct dentry
ディレクトリツリー内のファイルの場所を追跡します。
答え2
私はその中で答えを見つけました。オープンシステムコールのドキュメント:
POSIXは、「オープンファイルの説明」という用語を使用して、システム全体のオープンファイルテーブルのエントリを表します。他の文脈では、このオブジェクトは、「オープンファイルオブジェクト」、「ファイルハンドル」、「オープンファイルテーブルエントリ」、またはカーネル開発者という用語で構造ファイルとも呼ばれます。ファイル記述子がコピーされると(dup(2)または同様の方法を使用して)、コピーは元のファイル記述子と同じオープンファイル記述を参照するため、両方のファイル記述子はファイルオフセットとファイルステータスフラグを共有します。これらの共有はプロセス間で発生する可能性があります。 fork(2)によって生成された子プロセスは、親プロセスのファイル記述子のコピーを継承し、これらのコピーは同じオープンファイルの説明を参照します。ファイルの各 open(2) は新しいオープンファイル記述を生成します。したがって、1つのファイルinodeは、複数の開かれたファイル記述に対応することができます。
答え3
私はこの質問を主に用語、特に「ファイルテーブル」に関連すると解釈します。
以前の実装を見ると、システムで開いているすべてのファイル記述のコレクションが配列であることがわかります。プロセスに新しいオープンファイル記述が必要な場合は、配列で未使用のスロットを検索し、そのスロットへのポインタが返されます。たとえば、falloc
下部を参照してください。http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/fio.c
このシステムでは、「ファイルテーブル」はシステム全体に適用されますstruct file
。
今日開かれたファイル記述は、固定サイズの配列で未使用のスロットを選択するよりも柔軟なメカニズムによって動的に割り当てられます。システム上のすべての開いているファイルの説明のコレクションは、連続配列などの設定でソートする必要はありません。したがって、各動的メモリ割り当てプールを「テーブル」と考えない限り、「ファイルテーブル」はもうありません。
ウィキペディア図の「ファイルテーブル」は、開かれたファイル記述セットです。ファイル記述子は、ファイル記述を開くポインタ配列へのインデックスです。開かれたファイルの記述は常にいくつかの配列の数値インデックスではなく、これらのポインタを介してアクセスされるため、連続したボックス列で描画するのは少し誤解を招く可能性があります。それを「テーブル」と呼ぶことは、このような誤解を招くイメージを強化します。
しかし、これはかなり一般的な使い方なので、近いうちに消えるとは思わない。
答え4
お客様の要件が明確ではないため、理解しようとしています。しかし、私が正しく理解した場合、複数のプロセスが同じファイルにどのように書き込むことができるかを尋ねますか? Linuxでは、デフォルトではファイルはプロセスによってロックされず、複数のプロセスが常に同じファイルに書き込むことができます。もちろん、ファイル形式が破損する危険があります。書き込みは一度に1つのバッファである傾向があります。 (ほとんどの場合、これはフルテキスト行を意味し、ファイルがパブリックログであり、複数のプロセスがここに書き込む場合はうまく機能します。)バッファリングされたファイルを使用できますが、ファイルを開くときにデフォルト以外の追加オプションを選択する。
ランダムIOを使用して開かれたファイルは、複数のプロセスで開くと実際に歪む可能性があり、このタイプのIOを安全に使用するにはファイルロックが必要になる場合があります。
もう1つの関連する質問は、プロセスがファイルに頻繁にまたはまったく書き込まれていない場合でも、実行中のプロセスによってファイルが開いたままになるかどうかです。 「削除」しても、ファイルはディスク領域を占有し続けます。プロセスによって使用されるディスク容量は、ファイルを閉じてファイルハンドルを解放した後にのみ回復されます。
開いているファイルの詳細を学ぶもう1つの場所は/ procディレクトリ、特に/ proc / PID / fdです。これは、特定のPIDに対してプロセスがどのファイルを開いているかを確認する方法です。