Program logic bugs vs input/environmental errors

[Dicebot via Digitalmars-d]

On Saturday, 4 October 2014 at 19:36:02 UTC, Walter Bright wrote:
> 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.

This is not different from fiber or thread based approach. If one 
uses only immutable data for inter-thread communications (== does 
not use inter-process shared memory) same gurantees and reasoning 
come. And such design allows for many data optimizations hard or 
impossible to do with process-based approach.

There is no magic solution that does not allow to screw up in 
100% of cases whatever programmer does. Killing process is 
pragmatical default but not a pragmatical silver bullet and from 
pure theoretical point of few it has no advantages over killing 
the thread/fiber - it is all about chances of failure, not 
preventing it.

Same in Erlang - some failure warrant killing the runtime, some 
only specific process. It is all about the context and programmer 
should decide what is best approach for any specific program. I 
am fine with non-default being hard but I want it to be still 
possible within legal language restricions.