辞書が壊れない仮名漢字変換エンジンの作者を雇うのは案外に難しいのかもしれない，という話
ファイルクローズと内容の同期
MS-DOS ならいざ知らず、最近の OS なら f.close() するときに「バッファの flush」と「ファイルの unlock」の両方をしてくれる。つまり OS が面倒見てくれるから、必要な後処理は OS に任せてしまいましょう、ということ。プログラマーが勝手に unlock して問題になるくらいなら、OS 任せにしたほうがいい。resource を管理するために OS があるんだから。
先日 Windows でまさにこの話を追いかけていたばかりなので，ちょっと気になって軽く調べてみました．
どうやら Linux での日常的な風景も，Windows でのそれと基本的には同じ．つまり，デフォルトでは遅延書き込みを活用しつつ，ファイルクローズでのディスクへのデータフラッシュは必ずしも保証されない，というもののようでした．
- Linux では確かに close(2) で対象ファイルシステムの flush を呼ぼうとしているが，ext3 や reiserfs 等これが実装されていないファイルシステムが普通に使われている．この場合 close(2) から返ってきても書き込んだ内容がディスクに書き込まれているとは限らない．
- Windows NT カーネルでの CcDirtyPageThreshold に相当するものとして，Linux には proc/sys/vm/dirty_ratio というのがあるらしい．
要するに Linux でも，書き込みプロセス終了後にまだ数百 MB のディスク書き込み待ちデータが残っている可能性を覚悟せよ，というわけですな．他の OS も気になるところ．
あとはまあ OS レベルではなくてライブラリレベルで行われているバッファリング管理との兼ね合いも．
ソースレビューで File I/O のタイミングバグを見つけきる自信がない
しかしまあ，ここ の PPT ファイル 17 ページ目 の田畑さんのセリフじゃないですが，「なぜか壊れる」って問題が後を絶たないのもなんとなく分かる気がします．果たして私がソースレビューをしてこの手のタイミングバグを見つけれるでしょうか？ なんだか全然自信がありません．
そうやって考えてみると，辞書が壊れない仮名漢字変換エンジンの作者を雇うのは案外に難しい話なのかもしれませんね．世のデスクトップアプリケーションの開発者達は，人知れずこういった人類の敵と戦っているんでしょうか．
過去の関連記事
更新履歴・追記
- 2008年3月19日
- こちらの日記では，(引用元の議論をすっ飛ばして) 単に OS にとっての「バッファの flush」のみを考えてます．それに絡んでちょっとだけ本文修正．引用元の話では，ライブラリレベルでのバッファ管理もチェックした方が良さそうな気がしますね．ちなみに .NET でも似たような話があって，StreamWriter や FileStream が内部で書き込みバッファを持っているために，書き込みがロストするシナリオがあったり*1．
