4 ms·
Guess it’s the same difference between caught exceptions and panics, you can either recover or you cannot?
by lnxg33k1 3y ago
Guess it’s the same difference between caught exceptions and panics, you can either recover or you cannot?
- op00to 3y agoNo, a hard error in this case is one that is triggered by a hardware interrupt and is not interruptible by the system. This is explained in the article.
- deleted 3y ago[deleted]
- moritonal 3y agoFun fact, your question was 7% the length of the article which clearly answered your question.
- lnxg33k1 3y agoWhat were the odds of that happening?:0
- asveikau 3y agoIt 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.