Half-baked thought: Out-of-process asserts

[Nick Sabalausky (Abscissa)]

It seems pretty well established around here that:

1. Doing anything after a process has entered an unknown state is 
dangerous, and the more activity, the more danger (Note also, the 
transition to an unknown state actually occurs *before* any assert which 
is intended to detect it.)

2. For practical reasons, some things currently still need to be done in 
the process which is already in an invalid state: Evaluating the assert 
in the first place, generating a diagnostic message, generating the 
stack trace, etc...

What if a compiler (or library, standard tool, etc...) could 
automatically add an additional separate OS process to the program (or 
perhaps some other form of encapsulation that would isolate it from any 
corruption in the main process), and it is in this separate process 
where the compiler would insert the code responsible for one or more of 
the following:

- Generating stack traces upon detection of an assert failure (or 
bounds-check violation, or out-of-memory, etc).
- Formatting the custom assert failure string.
- Anything additional data gathering? Like a core dump?
- Display/log/report these diagnostics.
- Optionally restart the main process, depending on the type of program.
- Maybe even *performing* the assert/etc. checks by closely monitoring 
the main process and being aware of its state and memory layout.

The idea of course being to even further minimizing the work the errant 
process needs to do.

Discussion questions:
- What would be the feasibility of the various parts of this?
- Would this be an improvement or not?
- What would be the downsides, and how serious would they be?