02-Apr-2013 00:34, Ali Çehreli пишет:
On 04/01/2013 12:44 PM, Dmitry Olshansky wrote:> 01-Apr-2013 20:00, John
Colvin пишет:
>> Therefore, you're better off not trying to cleanup if program state
>> could be invalid.
>
> Data is corrupted no matter if you just fail to write it in a consistent
> state (sudden assertion in some 3-rd party library) or corrupt
> accidentally by bad write (during cleanup on corrupted RAM).
The failed assertion may be the moment when the program detects that
something is wrong. A safe program should stop doing anything else.
And that's precisely the interesting moment. It should stop but the
definition of "stop" really depends on many factors. Just pretending
that calling abort is a panacea is totally wrong IMO.
BTW what do you exactly mean by "safe" program?
> Therefore you should always try to orderly cleanup but do not rely on it
> to actually work at all circumstances (thus backups, commits/save
> points, watchdogs and whatnot).
A safe program must first guarantee that that cleanup is harmless, which
is not possible when the program is in an invalid state.
There could a lot of ways to do that even in "illegal" state. Restore
and conservative reconstruction of valid state is often possible (like
restoring files on a faulty hard drive) with a help of certain tricks
you can get high estimates of these actions to succeed.
Once you have resigned yourself to black and white - valid /invalid
there is no way to go indeed.
Imagine sending
almost infinite number of "cleanup" commands to a device that can harm
people who are around it.
These are far better off with built-in hardware fail-safe switches and
redundant circuitry.
Just suddenly stopping the program in the control of a spinning blade
that cuts through somebody's tissue is not good enough.
Ali
--
Dmitry Olshansky
