Null references (oh no, not again!)
Walter Bright
newshound1 at digitalmars.com
Wed Mar 4 03:40:58 PST 2009
Denis Koroskin wrote:
> On Wed, 04 Mar 2009 13:55:57 +0300, Walter Bright
>> If software is in your flight critical systems, the way one proceeds
>> is to *assume skynet takes it over* and will attempt to do everything
>> possible to crash the airplane.
>
> Assume you got a null-derefence under Linux. How are you going to
> recover from it? You can't catch the NullPointerException, so your
> program will fail and bring down the whole system *anyway*.
You design your critical system so it is not vulnerable to the failure
of a subsystem of it, even if that subsystem is powered by linux.
For example, you might have two computer systems controlling the
process. They vote, and if they disagree, they both are removed and the
backup is engaged. The two systems use different operating systems - say
one linux the other windows, they use different software written with
different algorithms in different languages.
The space shuttle, for example, had 4 independent flight control
computers voting, and a 5th (with reduced capability) that could be
manually brought online in case the 4 primaries all failed.
Google did an interesting design for their Chrome browser. Each tab in
it was powered by a separate process, meaning the hardware isolated it
from the operation of the other tabs. So if the browser crashed in one
tab, it wouldn't affect the other ones.
I've read elsewhere that if you want to create a robust system, you
break it up into different modules and run those modules as separate
processes (not just separate threads) that communicate via interprocess
communication. Any particular module dying could then be restarted
without affecting the rest of the modules.
The wrong way to do it is to lump everything into one gigantic process.
Then, any failure brings everything down.
More information about the Digitalmars-d
mailing list