3 ms·

> The computer could easily solve the problems without displaying this, while it provided a back-up version of the system for us, so that we could continue to w

by GTP 3y ago

> The computer could easily solve the problems without displaying this, while it provided a back-up version of the system for us, so that we could continue to work with our tasks undisturbed" How could this work? Teorically, the OS could detect that an application crashed and start it again. But to restore the state the application was in before it crashed, it would need to scan the application's memory and derive the state from it, hopefully without also recreating the conditions that lead to the crash. While this could maybe be done, it would require the OS to know the application's internals extremely well, so it isn't feasible to apply this at scale. Or am I missing a simpler way to do this? Maybe the OS could save snapshots of the application's status. This way it wouldn't need to know the application's internals, but there would still be the problem of how to know which is the last good status that will not cause a crash a few moments afterward.

jesprenj 3y ago
Perhaps you are describing Erlang? https://en.wikipedia.org/wiki/Erlang_(programming_language)#:~:text=%22Let%20it%20crash%22%20coding%20style https://en.wikipedia.org/wiki/Erlang_(programming_language)#...
- GTP 3y ago
  Wikipedia says: "When a process crashes, it neatly exits and sends a message to the controlling process which can then take action, such as starting a new process that takes over the old process's task" But this seems only a small piece of what would be needed. And if the idea is to have a main process spawning a tread (or process) for each "thing" it has to do so that the thread can be neatly re-spawed in case of failure, how is this much better done in Erlang than in any other programming language? Can you please elaborate?
wizofaus 3y ago
Further, if you restore an application's state to exactly what it was before it crashes, computers being the annoyingly deterministic machines they are, there's really only one possible outcome...(*) State isn't what you want to restore, it's "valuable user-created information". And I don't know of any platforms where you can clearly mark data as belonging to that category. (*) accepted, some crashes will occur due to things outside the application's control, and may conceivably succeed on retrial - but even that relies on being able to restore application state to some "last known good" state.

by GTP 3y ago

jesprenj 3y ago

Perhaps you are describing Erlang? https://en.wikipedia.org/wiki/Erlang_(programming_language)#:~:text=%22Let%20it%20crash%22%20coding%20style https://en.wikipedia.org/wiki/Erlang_(programming_language)#...

GTP 3y ago
Wikipedia says: "When a process crashes, it neatly exits and sends a message to the controlling process which can then take action, such as starting a new process that takes over the old process's task" But this seems only a small piece of what would be needed. And if the idea is to have a main process spawning a tread (or process) for each "thing" it has to do so that the thread can be neatly re-spawed in case of failure, how is this much better done in Erlang than in any other programming language? Can you please elaborate?

wizofaus 3y ago

Further, if you restore an application's state to exactly what it was before it crashes, computers being the annoyingly deterministic machines they are, there's really only one possible outcome...(*) State isn't what you want to restore, it's "valuable user-created information". And I don't know of any platforms where you can clearly mark data as belonging to that category. (*) accepted, some crashes will occur due to things outside the application's control, and may conceivably succeed on retrial - but even that relies on being able to restore application state to some "last known good" state.