Comment Re:Better recovery... (Score 1) 411
Anyone here do kernel programming?
A common practice in kernel programming when encountering a totally unexpected situation is to "panic". The unexpected situations where this is acceptable are often one of two classes:
1) critical failure of a critical piece of hardware (e.g. your root disk going out to lunch), uncorrectable memory errors (but detectable), etc.
2) programming errors. (generally "bugs".) When developing code that makes certain assumptions, its often a good idea to validate those assumptions with something called an "assertion". (For example, an assumption that a linked list is properly terminated can be checked, or that the caller owns a particular lock, etc.)
In both cases, the response is to "crash" (or "panic").
Why do we do this? First, we've encountered a situation from which we do not have any realistic hope of recovering... so rather than risk data corruption or worse problems later down the road, we crash, to "stop the hemorrhaging" so to speak.
Second, this a good panic will also cause a dump of the system state to be taken, so that it can be analyzed later. In the case of hardware failure, it may give some clue as to what the bad component is that needs to be replaced. In the case of a programmer error, it often provides the details necessary to find and fix the bug.
Its not unreasonable to believe that situations like this could come up for application programs as well.
However, one thing that is _unacceptable_ for a kernel to do, is to crash just because a user happened to send bad input, or a network happened to spew bad data. (Errors _inside_ the chassis can cause a panic... errors from _outside_ the chassis should not.)
I think M$ have some debugging to do...
A common practice in kernel programming when encountering a totally unexpected situation is to "panic". The unexpected situations where this is acceptable are often one of two classes:
1) critical failure of a critical piece of hardware (e.g. your root disk going out to lunch), uncorrectable memory errors (but detectable), etc.
2) programming errors. (generally "bugs".) When developing code that makes certain assumptions, its often a good idea to validate those assumptions with something called an "assertion". (For example, an assumption that a linked list is properly terminated can be checked, or that the caller owns a particular lock, etc.)
In both cases, the response is to "crash" (or "panic").
Why do we do this? First, we've encountered a situation from which we do not have any realistic hope of recovering... so rather than risk data corruption or worse problems later down the road, we crash, to "stop the hemorrhaging" so to speak.
Second, this a good panic will also cause a dump of the system state to be taken, so that it can be analyzed later. In the case of hardware failure, it may give some clue as to what the bad component is that needs to be replaced. In the case of a programmer error, it often provides the details necessary to find and fix the bug.
Its not unreasonable to believe that situations like this could come up for application programs as well.
However, one thing that is _unacceptable_ for a kernel to do, is to crash just because a user happened to send bad input, or a network happened to spew bad data. (Errors _inside_ the chassis can cause a panic... errors from _outside_ the chassis should not.)
I think M$ have some debugging to do...
