进程死后，io_uring 的 I/O 还在运行？
Is There I/O After Death? What Happens to Io_uring When a Process Dies
大多数人直觉认为，进程被 kill 并回收后，其 I/O 也会随之终止。但在 Linux 的 io_uring 机制下，这一直觉是错误的：进程虽已死亡，其提交的写请求仍可能在内核中存活并继续写入存储。我通过实验验证了这一现象，发现普通 io_uring 在进程退出后仍可能完成延迟写入，而 SQPOLL 和原生 AIO 则会在 waitpid() 中等待 I/O 完成。这意味着，若你的恢复协议依赖 waitpid() 作为 I/O 屏障，可能会遭遇严重问题。解决方案是引入显式锁机制，确保旧进程的 I/O 彻底结束前，新进程无法接管设备。
waitpid() 告诉你进程已死，但并未告诉你它的 I/O 也已死亡。
HN 评论区
34- PeterWhittaker
这种异步行为引发了一些有趣的问题：这究竟是 bug 还是按设计预期运行的？io_uring API 是否应该提供控制选项，让调用方应用程序自行决定？
对于同步的机器内调用，我们通常理所当然地认为，待处理的修改会随着调用方进程的结束而消失。
但在机器间通信中，我们通常理所当然地认为，发送方机器及其整个本地环境可能会消失，但其发送的操作仍会完成。
当然，也有例外，尤其是当 API 或系统提供原子性、一致性检查等功能时。
但如果没有明确的设计意图，或者更理想地说是调用方的意图，那么对于异步机器内调用的情况，双方观点都能自圆其说。
我想我的想法并非认为这种情况会发生，而是认为它是在隐式发生的。
- pianom4n
这段 AI 生成的文字读起来真让人难受。
- blackoil
你的进程是印度教、佛教还是基督教的？
- a-dub
我敢打赌，如果你 mmap 了一个大文件，弄脏了大量页面，然后退出进程并观察磁盘上的文件，你也会看到进程退出后仍有写入操作在发生。
- fooker
如果这真的是异步的，我就不明白 IO 与进程生命周期解耦有什么问题。
如果你希望在进程死亡时停止 IO，实现这一机制所需的开销很可能会拖慢整体性能。