アカウント名:
パスワード:
・C言語の高水準入出力 printf(3) とか fputs(3) で出力した内容はキャッシュされるので fclose(3) とか fflush(3) とかで吐き出して戻り値を確認しないと正常に出力されたことは保証されない。・exit(3) なり main() からの return で暗黙にフラッシュした場合はエラーチェックできないので、失敗してもわからない。
というのは基本仕様なので知っとく必要がある。/dev/full とかだけでなく、write(2)で発生するあらゆるエラーの可能性がある。
C言語の仕様と離れるけど補足しておくと、書き込み先が NFS のような場合にはカーネルが遅延書き込みをするので fflush(3) が成功したとしてもまだ十分ではない。あとから遅延してエラーが帰ってくるかもしれないので fclose(3) の戻り値を確認するまでは安心できない。
別件としてカーネル内にもページキャッシュがあるので、ディスクドライブへ書き込みされたことを保証したいなら fsync() なり sync() なりを検討する必要もある。
> 別件としてカーネル内にもページキャッシュがあるので、ディスクドライブへ書き込みされたことを保証したいなら fsync() なり sync() なりを検討する必要もある。
つまり書き込み保証を移植性のある方法で行うことは不可能
どっかで「syncは最低でも3回やれ」って記述を見た気がする。
1回目のsyncシステムコールは、syncシステムコールは非同期処理なため、バッファのフラッシュを要求するが、書き出し完了前に返ってくる。
2回目のsyncシステムコールは、1回目の処理が終わるまでブロックされるので、返ってきた時には、1回目の要求によるバッファのフラッシュができたことが保証できる
3回目は何の意味も無いおまじない
syncなのにasyncなのかややこしい
3回目は前のどちらかでtypoしたときのために
それは大昔の sync() の実行が非同期だった頃の風習。(BSD 系だと今でも現役?)Linux だと kernel 1.3.21 (1995年8月)以降は同期で終了を待つので1回で十分。
単発の発行は非同期だがシリアライズするためのロックは取る、という挙動に由来していたはず…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
/dev/full 関係ないじゃん。 (スコア:5, すばらしい洞察)
・C言語の高水準入出力 printf(3) とか fputs(3) で出力した内容はキャッシュされるので fclose(3) とか fflush(3) とかで吐き出して戻り値を確認しないと正常に出力されたことは保証されない。
・exit(3) なり main() からの return で暗黙にフラッシュした場合はエラーチェックできないので、失敗してもわからない。
というのは基本仕様なので知っとく必要がある。
/dev/full とかだけでなく、write(2)で発生するあらゆるエラーの可能性がある。
Re:/dev/full 関係ないじゃん。 (スコア:2, 興味深い)
C言語の仕様と離れるけど補足しておくと、書き込み先が NFS のような場合にはカーネルが遅延書き込みをするので fflush(3) が成功したとしてもまだ十分ではない。
あとから遅延してエラーが帰ってくるかもしれないので fclose(3) の戻り値を確認するまでは安心できない。
別件としてカーネル内にもページキャッシュがあるので、ディスクドライブへ書き込みされたことを保証したいなら fsync() なり sync() なりを検討する必要もある。
Re: (スコア:0)
> 別件としてカーネル内にもページキャッシュがあるので、ディスクドライブへ書き込みされたことを保証したいなら fsync() なり sync() なりを検討する必要もある。
つまり書き込み保証を移植性のある方法で行うことは不可能
Re: (スコア:0)
どっかで「syncは最低でも3回やれ」って記述を見た気がする。
Re:/dev/full 関係ないじゃん。 (スコア:2)
1回目のsyncシステムコールは、syncシステムコールは非同期処理なため、
バッファのフラッシュを要求するが、書き出し完了前に返ってくる。
2回目のsyncシステムコールは、1回目の処理が終わるまでブロックされるので、
返ってきた時には、1回目の要求によるバッファのフラッシュができたことが保証できる
3回目は何の意味も無いおまじない
Re:/dev/full 関係ないじゃん。 (スコア:1)
syncなのにasyncなのかややこしい
Re: (スコア:0)
3回目は前のどちらかでtypoしたときのために
Re:/dev/full 関係ないじゃん。 (スコア:1)
それは大昔の sync() の実行が非同期だった頃の風習。(BSD 系だと今でも現役?)
Linux だと kernel 1.3.21 (1995年8月)以降は同期で終了を待つので1回で十分。
Re: (スコア:0)
単発の発行は非同期だがシリアライズするためのロックは取る、という挙動に由来していたはず…