> i'm not sure why editor is the case that's being bandied about. I'm not sure why anyone should be listening to my ramblings...
I assume that C/R or migration is not an atomic operation. If it were atomic, that's the entire problem dealt with. If it's not atomic, there are potential race conditions, specifically if the stimuli to the entity being checkpointed are not to be aware of the checkpoint. As one cannot determine in advance which stimuli may be affected by race conditions, one has to eliminate all possibilities: 90% is just not good enough. To answer the question, an editor makes a fine example because I, the human stimulus to the editor, must not notice that a keystroke was missed while the migration took place. But see below... In my uneducated opinion, this means that the boundaries (namespace) for the target of a checkpoint must be totally specified. Each instance where a boundary is being crossed, like in the case of a remote connection, but also where contentions are possible, there has to be a mechanism to control possible races. Burdening normal applications with such controls may be very inefficient. The alternative, much closer to natural (biologically evolved) systems may be to omit all "locks" and instead deal with the errors a posteriori; if they are detected, that is. Using fault tolerance in such a situation is even more demanding of resources, but it resembles natural "intelligence" a lot more closely. I'm not sure how well Moore's Law would apply to such an approach. ++L
