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.
