Rendered at 16:13:17 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
PeterWhittaker 22 hours ago [-]
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.
eivanov89 21 hours ago [-]
Thank you very much for a very nice annotation/summary and sharing your thoughts.
pianom4n 24 hours ago [-]
The AI prose is painful.
collinstevens 22 hours ago [-]
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.
eivanov89 21 hours ago [-]
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.
pianom4n 21 hours ago [-]
Just don't. Your older posts are perfectly fine and much preferable to the most recent two.
eivanov89 21 hours ago [-]
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.
magicalhippo 21 hours ago [-]
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.
eivanov89 21 hours ago [-]
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.
throw-the-towel 20 hours ago [-]
Maybe you should just patch a grammar problem instead of rewriting the whole sentence. (I'm not blaming you but just sharing my experience, I suspect your first language might be a Slavic one like mine.)
eivanov89 19 hours ago [-]
Thanks for sharing. I didn't expect my slavic accent to be so strong to be visible in text and even pass through AI edits :)
throw-the-towel 19 hours ago [-]
Well, to be completely honest with you, it is obvious in your comments here. But my point was, keeping your Slavic accent and fixing the most glaring places with the help of AI is probably better than letting AI rewrite large portions of your text into "Better English". People do hate the AI accent these days, you know.
porridgeraisin 2 hours ago [-]
TBH, your username gives that part away atleast. My mind went to slavic when I saw the "ov" - it might be factually wrong, but thats waht happened.
20 hours ago [-]
w0rd-driven 19 hours ago [-]
If you're going for just grammar and spelling, Grammarly has been around for ages and doesn't try to rewrite everything. I'm a native speaker and I don't trust any LLM to retain my style because diffing paragraphs or reworking sections is tedious as hell. I'm reeeeeally lazy and the only workflow I am tempted to do is a rough draft from an LLM, a full rewrite from me, and something like Grammarly for small mistakes. Anything over a single iteration feels like pulling teeth because it's never as subtle as you tell it to be. It truly feels like giving a typewriter to monkeys.
gib444 20 hours ago [-]
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
pianopatrick 20 hours ago [-]
I wonder what would happen if you just told the AI to speak in broken english...
Hilarity may ensure.
eivanov89 20 hours ago [-]
Fair enough.
rcxdude 13 hours ago [-]
TBH I don't think it's that bad: the article is not hard to read and pretty informative (and is not just a copy + paste from a prompt), it's just got a hint of that tone which can grate just because it's rendered so cliche by LLM writing.
eivanov89 6 hours ago [-]
Thank you, that's actually was my actual attitude: found interesting things -> used AI to polish notes and quick draft -> "Hey folks, here is a cool thing I've found".
blackoil 23 hours ago [-]
Is your process Hindu, Buddhist, Christian?
fooker 20 hours ago [-]
A process is monotheistic because everyone is created by PID 1.
eivanov89 20 hours ago [-]
But when process dies, might it hope to become init on next reboot?
MathMonkeyMan 19 hours ago [-]
I'm a lowly shell, but in another life I aspire to achieve greatness through docker.
fooker 13 hours ago [-]
Start a cult with init=/bin/????? in your bootloader ;)
a-dub 18 hours ago [-]
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.
fooker 20 hours ago [-]
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.
eivanov89 20 hours ago [-]
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.
charcircuit 18 hours ago [-]
Can you explain your thinking? From my understanding of the issue as an extreme example you could have a "write a backdoored .bashrc, then wait 5 minutes" repeated a thousand times queued as async i/o. If malware did this you couldn't just kill the process to stop it. You would have to shutdown the machine.
Being able to stop this loop by just killing the process is a cleaner abstraction from my perspective.
fooker 13 hours ago [-]
Security and performance are often have different, contradictory needs.
The meltdown+spectre saga showed this for speculative execution. This is no different.
charcircuit 12 hours ago [-]
Typically there is also a latency trade off, so you can choose security and performance while losing latency. Systems should not depend on processes being fast to terminate anyways so making it slower in this case is fine.
charcircuit 22 hours ago [-]
I feel like this is a Linux bug. Linux shouldn't cleanup a process until it has finished execution.
Unrelated: My cat died. Saddest day of my life. I watched the light leave his eyes and still wonder where he went.
I looked it up and it said that the last thing to go when dying is probably your hearing.
When you die, typically you lose your sight first, then your bodily sensations, and 1-by-1 all your sensory channels turn off: Balance, equilibrium, proprioception, until you are like an empty force flying through infinite darkness, all your thoughts still in tact, knowing what is happening to you, and in the background you can still hear everyone in the room, until the sounds too begin to fade and distort into a light buzzing noise that gets higher and higher pitched like a zipper zipping up your last waking experience in a metaphorical body bag to be tossed off the edge of time.
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.
> 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.
Or that they want AI text over imperfect English
Hilarity may ensure.
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.
Being able to stop this loop by just killing the process is a cleaner abstraction from my perspective.
The meltdown+spectre saga showed this for speculative execution. This is no different.
Unrelated: My cat died. Saddest day of my life. I watched the light leave his eyes and still wonder where he went.
I looked it up and it said that the last thing to go when dying is probably your hearing.
When you die, typically you lose your sight first, then your bodily sensations, and 1-by-1 all your sensory channels turn off: Balance, equilibrium, proprioception, until you are like an empty force flying through infinite darkness, all your thoughts still in tact, knowing what is happening to you, and in the background you can still hear everyone in the room, until the sounds too begin to fade and distort into a light buzzing noise that gets higher and higher pitched like a zipper zipping up your last waking experience in a metaphorical body bag to be tossed off the edge of time.