当我在这里谈到停止问题时，听起来不终止是要避免的事情，而且停止问题使我们无法知道程序/算法是否良好。
但是当我想到它时，终止程序不是例外而不是规则吗？我可以想到一类预期在有限时间内终止的应用程序：编译器。其他一切，从我正在使用的网络浏览器，到桌面环境，到文本编辑器，到外壳，再到托管 SO 的服务器，再到操作系统本身，都不应该自行终止。哎呀，即使是包管理器也应该要求用户确认。它们都打算无限期地继续运行，除非用户或系统管理员另有说明。
我的意思是，它真的很糟糕，以至于你无法证明某事会终止吗？如果有的话，证明某事会在有限的时间内退出将是一个错误，而不是相反。
【问题讨论】：
标签： halting-problem
我明白你的逻辑，但是虽然你提到的这些程序在无限循环中运行直到终止，你仍然可以随时使用退出功能终止它们。非确定性终止的问题是您不知道程序何时会释放对其正在执行的操作的控制，以便可以终止它。
考虑一下。您编写一个程序，它完成一个循环并再次开始它的循环。每个循环都类似于程序终止。但不是关闭程序，而是要求它重新开始。如果您在该程序中对无限循环进行函数调用，则程序将注意力集中在该函数上，从而有效地阻止所有其他功能，直到该循环完成为止。提示，从来没有。这被用户感知为程序冻结。
【讨论】：
程序的终止不是重点。这只是计算终止的一个容易解释的例子。这是一个实际的例子：
当您访问网页时，您可能会开始运行一些 Javascript。根据代码嵌入页面的方式，您可能必须等待此脚本终止，然后才能完全显示网页。如果脚本没有在某个时间限制内终止，您将收到如下消息：
（如图所示的 Chrome 对话框）
您应该以某种方式决定脚本是否正在取得进展，如果再多一点时间就会完成，或者它是否陷入无限循环。你可能不知道答案，所以你猜。你等到你厌倦了等待，然后放弃并杀死它，当你按下按钮时，不知道它是否距离完成还有 1 秒。
Chrome 不会告诉您该脚本已无可救药地卡住并且永远不会终止，因为检测出不可救药卡住的脚本需要解决停止问题。
而且它也不仅仅是页面加载。 Javascript（在 Web 客户端上下文中）是事件驱动的。当外部事件发生时（即您单击表单提交按钮）调用函数，并且在函数返回（终止）之前不会处理该事件。非终止脚本是个大问题。
【讨论】：
cp df ls mv ps rm wc cat cmp dig echo grep head ipcs sort tail mount patch gunzip pngtopnm xtermset mysqldump。不仅仅是编译器...