io_uring Outlives Its Process: When waitpid() Isn't an I/O Barrier
Is There I/O After Death? What Happens to Io_uring When a Process Dies
On Linux, killing and reaping a process doesn't always stop its I/O. For ordinary io_uring, writes submitted before death can complete after waitpid() returns, as demonstrated by a test using dm-delay and a busy NVMe queue. SQPOLL and native AIO, however, wait for I/O during teardown. The author explains the kernel paths and suggests using flock() as a barrier for fail-fast recovery protocols.
The process was gone. waitpid() had returned in about 3 milliseconds. And almost three seconds later, its writes arrived.
- PeterWhittaker
The asynchronous behaviour raises interesting questions as to whether or not this is a bug or working as intended, and whether or not the io_uring API should offer controls to allow the calling application to decide.
With synchronous intra-machine calls we mostly take it for granted that pending modifications die with the caller.
But with inter-machine communications we mostly take it for granted that the sending machine and its entire local area can disappear and operations it sent will complete.
Of course, there are exceptions, especially when APIs/systems offer atomicity, consistency checks, etc.
But without express design intent, or preferably caller intent, one can argue both sides of the asynchronous intra-machine case and be right.
I guess my thinking isn't so much that this happens as that it happens implicitly.
- pianom4n
The AI prose is painful.
- a-dub
i bet if you mmap'd a big file and then dirtied a ton of pages and then exited and watched the file on disk, you'd see writes occurring after the process exits as well.
- blackoil
Is your process Hindu, Buddhist, Christian?
- fooker
If it's truly asynchronous, I don't see the issue with IO being decoupled from process lifetime.
If you wanted to stop the IO at process death, the mechanism needed for this would introduce an overhead that would likely slow things down in general.