io_uring の書き込みはプロセス死後も生き続ける：waitpid() が I/O バリアにならない理由
Is There I/O After Death? What Happens to Io_uring When a Process Dies
Linux では、プロセスが SIGKILL で殺され waitpid() で回収された後も、通常の io_uring で送信された書き込みがカーネル内で生き残り、後からストレージに到達することがある。この記事では、dm-delay や NVMe キューの負荷を用いた実験でこの現象を実証し、SQPOLL やネイティブ AIO ではプロセスの終了処理が待ち時間として現れることを示す。さらに、flock() を使ったロックがバリアとして機能する理由を、カーネルのコードと struct file の参照から解説する。
プロセスの寿命と I/O の寿命は同じではない。通常の io_uring では、waitpid() はタスクが消えたことを教えてくれるが、その書き込みがまだ生きていることは教えてくれない。
HNでの議論
34- PeterWhittaker
非同期の挙動は、これがバグなのか意図された動作なのか、またio_uring APIが呼び出し元アプリケーションに決定を委ねるための制御を提供すべきかどうかについて、興味深い疑問を提起します。
同期のマシン内呼び出しでは、保留中の変更は呼び出し元とともに消滅するのが当然だと思い込んでいます。
しかし、マシン間通信では、送信元マシンとそのローカルエリア全体が消滅しても、送信された操作は完了するのが当然だと思い込んでいます。
もちろん、特にAPIやシステムが原子性や一貫性チェックなどを提供する場合には例外があります。
しかし、明確な設計意図、できれば呼び出し元の意図がなければ、非同期のマシン内ケースの両側を主張して正しいと言えます。
私の考えは、これが起こること自体よりも、それが暗黙的に起こることに問題があるのだと思います。
- pianom4n
AIの散文は痛々しい。
- a-dub
大きなファイルをmmapして、大量のページをダーティにしてからexitし、ディスク上のファイルを監視すれば、プロセス終了後も書き込みが発生するのを見られるだろうな。
- blackoil
あなたのプロセスはヒンドゥー教徒ですか、仏教徒ですか、キリスト教徒ですか？
- fooker
本当に非同期なら、I/Oがプロセスの寿命から切り離されていることに問題はないと思う。
プロセス終了時にI/Oを止めたいなら、そのために必要なメカニズムは一般的に処理を遅くするオーバーヘッドをもたらすだろう。