On Saturday, 1 November 2014 at 15:02:53 UTC, H. S. Teoh via
Digitalmars-d wrote:
I never said "component" == "process". All I said was that at
the OS
level, at least with current OSes, processes are the smallest
unit
that is decoupled from each other. If you go below that level of
granularity, you have the possibility of shared memory being
corrupted
by one thread (or fibre, or whatever smaller than a process)
affecting
the other threads. So that means they are not fully decoupled,
and the
failure of one thread makes all other threads no longer
trustworthy.
This is a question of probability and impact. If my Python
program fails unexpectedly, then it could in theory be a bug in a
c-library, but it probably is not. So it is better to trap it and
continue.
If D provides bound checks, is a solid language, has a solid
compiler, has a solid runtime, and solid libraries… then the same
logic applies!
If my C program traps on divison by zero, then it probably is an
unlucky incident and not a memory corruption issue. So it is
probably safe to continue.
If my program cannot find a file, it MIGHT be a kernel issue, but
it probably isn't. So it safe to continue.
If my critical state is recorded by a wall built on transactions
or full blown event logging, then it is safe to continue even if
my front might suffer from memory corruption.
You need to consider:
1. probability (what is the most likely cause of this signal?)
2. impact (do you have insurance?)
3. alternatives (are you in the middle of an air fight?)
