Yes! I have wanted an AI type supervisor at hand for so many years now.
That said, the facility is limited. There need to be a watchdog that works with the OS that identifies resource demanding or unresponsive threads and decides if they should be terminated or not.
-------------
But the comments here shows why this has been so long coming:
"There is no way to predict in what state the program will be in once the program is forced out of the loop,"
"So, breaking a program out of an infinite loop that could possibly be running other routines important to its operation is now a good idea..."
"Breaking out of a loop and letting the code progress in an unknown state is asking trouble."
"there's no way to know what the state of the app is after being forced out of the infinite loop."
"it tries to recover from infinite loops by BREAKING THE INTERNAL LOGIC."
"The point is that if you prematurely break out of a loop, you can no longer make ANY valid assumption about the state of your program."
"in principle this should never happen anyways."
The point is _exactly_ to break the faulty internal logic to save the external logic (remaining resources, the end user). It is a way to make realtime or soft realtime software (ideally, laptops) more robust.
I am fairly certain that concerns are misplaced because today this is what a user _do_ with a hung laptop, restart/force thread stop, and take the breaks. Frequent and stacked file backups has solved the file recover problem. The remaining problem is to get this automated and sandboxed without forcing restart.
The logic of a laptop is not the logic of a thread or interrelated threads. It is the logic of realtime use of an ecology of threads.
