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.
Note, that this also includes retaining process memory related to the I/O. In my experiment I used regular 4 KiB pages, which is smaller or equal to the I/O block size. However, in case of huge pages only a small fraction can be I/O related. And I suppose, that this small part would pin the whole page, which might have some sensitive information. Still protected, however, but who knows.
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.
I'm the author and I'm not native speaker, so please bear that in mind. However, I admit I've used AI for grammar and style. IMHO, the post is not fiction, I just wanted to communicate the ideas as clearly and effectively as possible.
Frankly speaking, you are the second (with this thread, the third) one, who says that. So, it looks that I really should write myself again with just grammar checks, not the style.
What I've done a few times is have the AI provide feedback, and then I rewrite myself based on the feedback. So I don't use what the AI suggests directly, just the essence if I agree.
That's a good approach. My sin is that if I like the sentence, I keep and don't rewrite. Because if I see it is good, I don't feel I should. And probably I don't see that "prose" is bad each time it is indeed bad.
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.
Note, that this also includes retaining process memory related to the I/O. In my experiment I used regular 4 KiB pages, which is smaller or equal to the I/O block size. However, in case of huge pages only a small fraction can be I/O related. And I suppose, that this small part would pin the whole page, which might have some sensitive information. Still protected, however, but who knows.
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.
Thank you very much for a very nice annotation/summary and sharing your thoughts.
Is your process Hindu, Buddhist, Christian?
A process is monotheistic because everyone is created by PID 1.
But when process dies, might it hope to become init on next reboot?
The AI prose is painful.
you can just feel it in your bones
> These are measured results backed by the Linux source, not a portable guarantee for every kernel, filesystem, device, or API called “AIO”.
> The interesting race window is there, but hard to see. So I made it larger.
I'm the author and I'm not native speaker, so please bear that in mind. However, I admit I've used AI for grammar and style. IMHO, the post is not fiction, I just wanted to communicate the ideas as clearly and effectively as possible.
Just don't. Your older posts are perfectly fine and much preferable to the most recent two.
Frankly speaking, you are the second (with this thread, the third) one, who says that. So, it looks that I really should write myself again with just grammar checks, not the style.
What I've done a few times is have the AI provide feedback, and then I rewrite myself based on the feedback. So I don't use what the AI suggests directly, just the essence if I agree.
That's a good approach. My sin is that if I like the sentence, I keep and don't rewrite. Because if I see it is good, I don't feel I should. And probably I don't see that "prose" is bad each time it is indeed bad.
It's easy to falsely assume readers expect you to be native, or that they are even native English speakers themselves
Or that they want AI text over imperfect English
I wonder what would happen if you just told the AI to speak in broken english...
Hilarity may ensure.
Fair enough.
I feel like this is a Linux bug. Linux shouldn't cleanup a process until it has finished execution.
Jens Axboe, the io_uring author, promissed to address this on X next week: https://x.com/axboe/status/2095856971912028536?s=20 Stay tuned.