2 ms·
It can be kind of hard to route an error that happens deep inside a kernel to an application. Disk errors happening after a deferred write are a classic exampl
by asveikau 3y ago
It can be kind of hard to route an error that happens deep inside a kernel to an application.
Disk errors happening after a deferred write are a classic example that's still applicable today. Your process might have succeeded a write(2) into cache and exited cleanly, then when it's time to write to disk, something bad happens. There's no way to tell an application that is long gone.
- becurious 3y agoBut you would use unbuffered writes if you really cared. Otherwise there’s nothing actionable that can be done by the application unless there was some kind of signal or callback / APC.
- asveikau 3y agoAll correct. You're making my same points. I'm illustrating a real world scenario where such a mapping may not be possible. Further, if the issue is a global problem, like filesystem corruption, it becomes even more ambiguous -- maybe that write could have worked or maybe it wouldn't, but the filesystem may just globally make everything read only and start failing writes. So my point is that these errors were meant for catastrophic failures that don't map neatly into being handled with the process. In a modern kernel there are way fewer of these conditions than was acceptable in the early 90s. But there are a few similar things that are still common.