書き込みが開始または完了すると、inotifyは通知をトリガーしますか？

ext3ファイルシステムの通常のファイルを介して通信する2つのプロセス、リーダーとライターを想像してみてください。 ReaderにはIN_MODIFYファイルの監視があります。 Writerは1回の呼び出しでファイルに1000バイトを書き込みますwrite()。リーダーはinotifyイベントを受け取り、fstatファイルを呼び出します。読者は何を見るか。

1. st_size読者が自分の文書に対する報酬として少なくとも1,000ドルを受け取ることができることは保証されていますか？私の実験によるとそうではありません。

2. Readerが実際に1000バイトを読むことができるという保証はありますかread()？

これは、I / Oバインディングの重いボックスで発生します。たとえば、sar約1秒の待ち時間が表示されます。私の場合、Readerは実際にinotifyイベントを受け取ってから10秒待ってから呼び出しましたが、stat結果が小さすぎました。

私が望むのは、ファイルが準備されるまでinotifyイベントが送出されないことです。実際に何が起こるのかは、write()Writerからの呼び出し中にinotifyイベントが発生し、データが準備されている限り、システムの他のプロセスで実際にデータを使用できることです。この場合、10秒では不十分です。

私はカーネルが実際に私が推測した方法でinotifyを実装していることを確認するために探しているようです。また、この動作を変更するオプションはありますか？

最後に、この動作を考えると、inotifyのポイントは何ですか？いずれにせよ、イベントを受け取った後は、データが実際に利用可能になるまでのみファイル/ディレクトリをポーリングできます。これを続けてinotifyを忘れることもできます。

***編集する**** まあ、よくあるように、私が見た行動は本当に意味があり、今は私が実際に何をしていたのか理解しています。 ^_^

実際にファイルがあるディレクトリのIN_CREATEイベントに応答しています。だから私は実際にファイルの生成に応答してファイルをstat（）しています。 IN_MODIFYイベントは必ずしも必要ではありませんが、後で到着する可能性があります。

IN_CREATEイベントが受信されると、ファイル自体のIN_MODIFYを購読し、IN_MODIFYイベントが受信されるまで実際にファイルを読み取ろうとしないようにコードを変更します。私はそこに小さなウィンドウがあり、ファイルへの書き込みを見逃す可能性があることを知っていますが、最悪の場合、ファイルは最大時間（秒）後に閉じられるので、これは私のアプリケーションに許可されています。