Most (all?) of the paper links appear to be dead. Here's some slides on the topic: http://roc.cs.berkeley.edu/retreats/winter_03/slides/candea_crashonly.pdf ht

Most (all?) of the paper links appear to be dead. Here's some slides on the topic: http://roc.cs.berkeley.edu/retreats/winter_03/slides/candea_crashonly.pdf http://roc.cs.berkeley.edu/retreats/winter_03/slides/candea_... Interesting to see a name put to this. I used this technique (not having heard of it before) when developing a short but finicky and critical cloud-coordinated cross-datacenter disaster recovery consensus algorithm a few years ago. There was a point at which the algorithm recorded its state and a timestamp to local storage, so progress and correctness were guaranteed in the face of a crash. I came to the same conclusions as these researchers -- this state transition did not need to be fast, but did need to be absolutely robust and well tested. So rather than code and test both the "happy path" and the crash-recovery path -- I just called `_Exit(1)` and only coded and tested the crash-recovery path. (It wasn't a perfect confluence of testing space -- my code exited in a way that did not trigger a core dump; whereas most failure modes did. But generally, core dumps bogging down an already-ill system were an issue we had to contend with.) Would be interesting to see a DSL designed around this technique -- a semi-persisted program state of sorts -- with the happy-path automatically generated as an optimization.