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?
