バッファリング I/O (stdio)

stdio は FILE オブジェクトを通じて、フォーマット処理、バッファリング、ストリーム状態、位置管理を提供します。バッファリングは多数の小さな操作を結合できますが、fwrite のたびにカーネルに入らないことを保証するものではなく、無バッファ時でも各 API が必ず 1 回のシステムコールに対応するとは限りません。データがどこに到達したかを判断するには、ライブラリインターフェース、低レベル I/O、永続化の各レイヤーを区別する必要があります。

FILE とファイルディスクリプタ

fd はプロセス記述子テーブル内の整数インデックスであり、FILE はさらにバッファカーソル、EOF/エラー状態、方向、ロックなどを保持します。fread は、すでにプリフェッチされたユーザーバッファから直接データを返す場合もあれば、バッファを埋めたり大規模な低レベル読み込みを行ったりする場合もあります。fwrite も同様に、バッファ経由または直接書き込みのパスを通過します。

glibc の _IO_FILE フィールドは実装の理解に役立ちますが、クロス libc での移植性のあるインターフェースではないため、アプリケーションコードで修正すべきではありません。また、FILE が必ずしも通常ファイルを指すわけではありません。例えば、メモリストリームは異なる低レベル操作を持つことがあります。

3つのバッファリング戦略

Linux における一般的な libc のデフォルトでは、ターミナルの stdout は行バッファ、通常ファイルの出力は全バッファ、stderr は無バッファになります。ファイルやパイプにリダイレクトすると、stdout の動作が変化する可能性があるため、同じプログラムでもターミナルでは即時出力され、パイプラインでは遅延して出力されることは矛盾しません。

setvbuf はストリームを開いた後、他の操作を行う前に呼び出し、戻り値を確認する必要があります。BUFSIZ は実装が提供するマクロであり、すべての FILE バッファのサイズが同じであるとは限らず、特定の glibc の値を移植性のある定数として記述すべきではありません。setvbuf

FILE *fp = tmpfile();
if (fp == NULL) return 1;
char storage[4096];
if (setvbuf(fp, storage, _IOFBF, sizeof storage) != 0) {
    fclose(fp);
    return 1;
}
/* fp を使用；storage がスコープ外になる前に fclose(fp) すること。 */
if (fclose(fp) == EOF) return 1;

これは関数内の断片であり、<stdio.h> が必要です。カスタムバッファはストリームが閉じられるまで存続しなければなりません。関数のローカル配列を、返される予定の FILE に渡すと、無効な参照が残る原因となります。

fwrite、fflush、fsync が保証する内容の違い

fwrite が完全な数を返しても、データがライブラリに受け入れられただけかもしれません。fflush が成功したことは、対応するユーザーバッファが低レベルの書き込み操作によって送信されたことを意味しますが、停電時でも永続化されることを保証するものではありません。通常ファイルで永続化の保証が必要な場合は、通常まず fflush を呼び出し、その後 fileno(fp) に対して fsync を呼び出し、それぞれエラーをチェックします。fflush(3)

fsync の対象はカーネルのファイル状態であり、まだ FILE の中に留まっているデータをフラッシュしてくれるわけではありません。新規作成やファイル名の変更におけるクラッシュ一貫性のためには、それを含むディレクトリの同期が必要な場合もあり、これは単一ファイルの内容同期とは異なります。fsync(2)

カーネルキャッシュも、任意の 1000 回の write を必ず 1 回の物理 I/O に結合するとは限りません。書き戻し、ファイルシステム、ブロックサイズ、デバイスキューなどが決定に関与します。「100 倍高速になる」や「システムコールは必ず 200ns」といった固定値を信じてはいけません。

fsync はなぜ FILE 内のデータを出せないのか？

まず 3 バイトをアペンドし、直接 fsync します：カーネルはまだこの 3 バイトを認識していないため、同期の保証はこれらを上書きしません。次に fflush し、最後に fsync して、3 層の帳尻を合わせます。低レベルのファイル行は送信済みの内容を保持し、同期をカーネルから「搬出・消去」するものとして描画しません。ファイルキャッシュはこれらのバイトを保持し続けることができるからです。

戻り値とエラーの正しい解釈

fread/fwrite は処理が完了した要素数を返します。size=1 の場合のみ、その数がバイト数に等しくなります。末尾のバイトを 1 バイトずつ処理する必要がある場合は、fread(buf, 1, capacity, fp) を使用することで、何バイト取得できたかをより明確に表現できます。

短い読み込みは EOF である場合もあれば、エラーである場合もあります。feof と ferror を使って区別します。EOF マーカは、末尾に到達しようとした際に設定されるため、while (!feof(fp)) は正しい読み込みループの条件ではありません。fread(3)

以下の関数は、呼び出し元が開いた 2 つのストリームをコピーし、成功終了時に出力をフラッシュします。ストリームのクローズは行わず、永続化の保証も提供しません。

#include <stdio.h>

int copy_stream(FILE *in, FILE *out) {
    unsigned char buf[8192];
    size_t n;
    while ((n = fread(buf, 1, sizeof buf, in)) != 0) {
        if (fwrite(buf, 1, n, out) != n) return -1;
    }
    if (ferror(in)) return -1;
    return fflush(out) == 0 ? 0 : -1;
}

書き込みエラーは、fwrite の直後に発生する場合もあれば、fflush や fclose の際に遅れて発生する場合もあります。クローズ時にエラーが報告されても、呼び出し元は元の FILE を有効なオブジェクトとして fclose の再試行に使用することはできません。エラーストリームに対して clearerr 後に再試行するかどうかは、原因と位置のセマンティクスに応じて設計する必要があり、盲目的に無限ループにしてはいけません。

書き込みが受け入れられた後でも、フラッシュ時にエラーが発生する可能性がある

Linux の /dev/full は書き込みに対して ENOSPC を返すため、ライブラリバッファがエラーを fflush まで遅延させる様子を、実際のディスクを一杯にする必要なくデモンストレーションできます。以下は glibc/Linux に限定した例で、全バッファ中に 3 文字を配置してから明示的にフラッシュします。full(4)

#include <errno.h>
#include <stdio.h>
int main(void) {
    FILE *fp = fopen("/dev/full", "w");
    if (fp == NULL) return 1;
    char buffer[1024];
    if (setvbuf(fp, buffer, _IOFBF, sizeof buffer) != 0) {
        fclose(fp); return 1;
    }
    int accepted = fputc('a', fp) != EOF;
    accepted = (fputc('b', fp) != EOF) && accepted;
    accepted = (fputc('c', fp) != EOF) && accepted;
    errno = 0;
    int flushed = fflush(fp);
    int saved = errno;
    int marked = ferror(fp) != 0;
    /* クローズ後、戻り値に関わらず、fp にアクセスしたり fclose を繰り返したりしないこと。 */
    int closed = fclose(fp);
    printf("accepted=%d flush_failed=%d ENOSPC=%d error_mark=%d close=%d\n",
           accepted, flushed == EOF, saved == ENOSPC, marked, closed);
    return !(accepted && flushed == EOF && saved == ENOSPC && marked);
}

delayed-error.c として保存し、コンパイルして実行すると、最初の 4 つのブール値は 1 になるはずです。close の結果は個別に表示され、同じフラッシュエラーを繰り返すことは要求されません。終了時の fclose の戻り値のみを見て、以前に発生した失敗を無視してはいけません。また、3 回の fputc が成功したからといって、データが書き込み完了したと宣言してはいけません。

読み書きと低レベル fd 操作の混在

更新ストリーム（r+、w+ など）で出力から入力に切り替えるには、fflush または位置決め操作が必要です。入力から出力に切り替える場合は、通常位置決め操作が必要ですが、直前の入力で EOF に到達していた場合は例外です。fseek/fsetpos などを明示的に使用して、方向と位置を同期させます。fopen(3)

stdio のプリフェッチにより、低レベルの fd オフセットはアプリケーションの消費位置よりも先に進むことがあります。fileno(fp) に対して直接 read を行うと、まだ消費されていないバッファを迂回する可能性があります。write の混在も出力順序を変更する可能性があります。1 つのオブジェクトで I/O レイヤーを統一するのが望ましいですが、混在させる必要がある場合は POSIX のアクティブハンドル調整ルールに従います。

fflush(stdin) はキーボード入力を空にする汎用的な方法ではありません。POSIX では位置決め可能な入力ストリームに対してバッファ破棄動作が定義されていますが、パイプとターミナルは同じ状況ではありません。

同一の更新ストリーム内での位置、方向、EOF の確認

update-stream.c として保存します。tmpfile はバイナリ更新ストリームを作成します。まず abcdef を書き込み、先頭 3 バイトを読み取ります。位置決め操作を使用して読み込みから書き込みへの切り替えを調整し、現在の位置の d を X に置換し、最後に abcXef を読み戻します。

#include <stdio.h>
#include <string.h>
int main(void) {
    FILE *fp = tmpfile();
    if (fp == NULL) return 1;
    int failed = 1;
    char data[7] = {0};
    if (fwrite("abcdef", 1, 6, fp) != 6) goto done;
    if (fseek(fp, 0, SEEK_SET) != 0) goto done;
    if (fread(data, 1, 3, fp) != 3 || memcmp(data, "abc", 3) != 0) goto done;
    if (fseek(fp, 0, SEEK_CUR) != 0) goto done;
    if (fputc('X', fp) == EOF) goto done;
    if (fseek(fp, 0, SEEK_SET) != 0) goto done;
    if (fread(data, 1, 6, fp) != 6 || memcmp(data, "abcXef", 6) != 0) goto done;
    if (feof(fp) || ferror(fp)) goto done;
    if (fgetc(fp) != EOF || !feof(fp) || ferror(fp)) goto done;
    clearerr(fp);
    if (feof(fp) || ferror(fp)) goto done;
    /* マーカをクリアしてもファイルの先頭には移動しないため、再度読み込むと EOF に遭遇する。 */
    if (fgetc(fp) != EOF || !feof(fp)) goto done;
    if (fseek(fp, 0, SEEK_SET) != 0 || feof(fp)) goto done;
    if (fgetc(fp) != 'a') goto done;
    failed = 0;
    puts("update and EOF transitions passed");
done:
    if (fclose(fp) == EOF) failed = 1;
    return failed;
}

コンパイルして実行：cc -Wall -Wextra update-stream.c -o update-stream、その後 ./update-stream。ちょうど 6 バイト読み込んだ時点で、アプリケーションの要求は満たされ、末尾を検出するための追加読み込みはまだ行われていません。次の fgetc で EOF が設定されます。clearerr は状態のみをクリアし、ファイル位置は移動しません。成功した fseek は位置決めと EOF のクリアの両方を行います。fseek(3)、ストリーム状態

ここで使用されている goto は FILE の一元的なクローズを実現し、各チェック分岐でリソースの漏れを防ぎます。これにより、失敗した I/O が自動的に回復するわけではありません。具体的な原因を報告する必要がある場合は、ジャンプ前にエラー情報を保存する必要があります。

fork はフラッシュされていないユーザーバッファをコピーする

fork 後、親プロセスと子プロセスはそれぞれ FILE 状態とユーザーバッファのコピーを持ち、低レベルのオープンファイル記述子は共有される可能性があります。両方が通常の exit でフラッシュする場合、フラッシュされていない同じ内容が 2 回書き出される可能性があります。

printf("before fork\n") が改行を含んでいても、stdout が全バッファにリダイレクトされている場合、必ずしもフラッシュされているとは限りません。シングルスレッドプログラムでは、適切な位置で明示的に fflush を呼び出し、その結果を確認できます。「改行があるから」とすべての出力環境で安全であると推論してはいけません。

マルチスレッドで fork 後、子プロセスは exec まで非同期シグナルセーフの制限を受け、ロック状態を整理するために stdio を任意に呼び出すことはできません。exec の失敗パスでは、通常、適切な低レベルレポートと _exit を使用し、継承されたバッファの重複フラッシュを避けます。_exit は stdio をフラッシュせず、通常の exit とは異なります。

順序、アトミック性、パフォーマンス

stdout と stderr に別々に書き込んでも、どちらもフラッシュされていれば、すべての外部コレクタで統一されたグローバル表示順序が保証されるわけではありません。厳密な順序が必要な場合は、同じ出力チャネルを使用するか、番号付きの記録プロトコルを採用します。

stdio の単一呼び出しには通常ストリームロックがありますが、複数の呼び出しで構成される 1 つのログは自動的にトランザクションにはなりません。複数のプロセスがパイプに書き込む場合、実際の低レベル write の長さと PIPE_BUF も考慮する必要があります。「1 回の fprintf」を「1 回のアトミックパイプメッセージ」と直接見なしてはいけません。

strace を使用して低レベルの write 回数を観察することで、バッチ効果を検証できます。バッファのサイズは、実際のスループット、レイテンシ、エラー動作を評価して決定します。ノンブロッキングネットワークイベントループでは、通常、fd とアプリケーションバッファを直接管理します。詳細は epoll とイベント駆動 を参照してください。

キーワード：stdio, FILE, setvbuf, fread, fwrite, fflush, fsync, buffering, EOF, fork, active handle