Program logic bugs vs input/environmental errors

[Walter Bright via Digitalmars-d]

On 10/4/2014 9:16 AM, Sean Kelly wrote:
> On Saturday, 4 October 2014 at 09:18:41 UTC, Walter Bright wrote:
>>
>> Threads are not isolated from each other. They are not. Not. Not.
>
> Neither are programs that communicate in some fashion.

Operating systems typically provide methods of interprocess communication that 
are robust against corruption, such as pipes, message passing, etc. The 
receiving process should regard such input as "user/environmental input", and 
must validate it. Corruption in it would not be regarded as a logic bug in the 
receiving process (unless it failed to check for it).

Interprocess shared memory, though, is not robust.



> I'll grant that the
> possibility of memory corruption doesn't exist in this case (a problem unique to
> systems languages like D), but system corruption still does.  And I absolutely
> agree with you that if memory corruption is ever even suspected, the process
> must immediately halt.  In that case I wouldn't even throw an Error, I'd call
> exit(1).

System corruption is indeed a problem with this type of setup. We're relying 
here on the operating system not having such bugs in it, and indeed OS vendors 
work very hard at preventing an errant program from corrupting the system.

We all know, of course, that this sort of thing happens anyway. An even more 
robust system design will need a way to deal with that, and failure of the 
hardware, and failure of the data center, etc.

All components of a reliable system are unreliable, and a robust system needs to 
be able to recover from the inevitable failure of any component. This kind of 
thinking needs to pervade the initial system design from the ground up, it's 
hard to tack it on later.