[govolckurself]

Pretty sure this is equivalent to solving the Halting Problem, which is... difficult, to say the least. But why should the OS try to stop you from making logic errors? Test your state machines. Test every transition you're interested in. In practice, it's not that big of an issue, and programs hang for more mundane reasons.

[yccs27]

The Halting Problem is undecidable only for Turing machines, but we are restricting ourselves to finite state machines - and with a finite number of states it must eventually either halt or repeat a previous configuration.

https://en.wikipedia.org/wiki/Halting_problem#Common_pitfall...

I'd go so far to say that this is a key advantage of FSMs - without Turing completeness you get much better options for theoretical analysis.

[qikInNdOutReply]

Im confused. We argue for the same point. The program must know. And it can know. It can perform regular check ins and the watchdog in the program internals should reset it properly out of an error state. With an error message and the ability to save previously done work.

I totally agree with you. Its very strange that the Operating System has to do basic controll flow jobs, as in Windows with the basic regular check ins by programs with the os. It should be part of every executable.

[anongraddebt]

The Redmond philosophy views running Windows update as basic control flow for any executable whatsoever.

[qikInNdOutReply]

Which still is by all means a externalized watchdog, which in addition is deactivated, if its not properly implemented and still working. So the philosophy itself is brokken by the programers and the users are used as sensor to find out wether the program executed properly.

A proper implementation would be, that windows for example during the installation could "starve" the process in a API or somewhere else into a internal timeout and expect that error to come up, to proof worthiness.