Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Justification :

Currently there is, as far as I'm aware, two options regarding loop checks :

- world.loop_checks = 0 ; when DM detects an infinite loop, it will ignore it and go on as usual. This is dangerous because it can lead to unexpected crashes which are hard to diagnose and to debug.

- world.loop_checks = 1 ; an infinite loop will just runtime and get switched to the background. In the case of a multiplayer game (ss13), it slows down the server to a crawl until someone manages to fix the problem (for instance, by deleting the instance of the object which is looping infinitely.)

Feature request :

- world.loop_checks = 2 ; if an infinite loop is detected, a runtime is produced and the proc is stopped.

So, if this kind of problem happen, it can still be identified but doesn't cause massive performance issues.

I'm not sure if there is already a way to work around this or if it's not in the design philosophy of byond, but I believe it could be useful.
I'm not sure if stopping the proc prematurely would necessarily be a better option. The real issue here is that some object in that codebase is responsible for an infinite loop, and that code needs to be addressed and corrected right away.

In this specific case obviously this suggestion would have improved the short-term performance on that particular run, but that's about it; the problem in the code would still exist. Most other games' infinite loops would see AI-controlled creatures freeze up, etc. And in SS13 I could see that if such a loop were doing something like rearranging power connections, you could end up with a very broken situation anyway that would interfere with the rest of the round.

That's not a no, though; I'll have to think about this one. I do see some benefit to having a simple sanity-check cutoff to deal with such a problem until the coders can fix it, as long as the coders do actually fix it.
Once the issue was identified, the problem was corrected. I see your point.
We do however tend to check runtimes for that kind of things and address these problems.

Thank you for taking the time to look at this.
Another thing is that loop checks and stack overflow protections checks are under the same variable, that is not runtime editable.

There are many times we would like to be able to guarantee a loop will never sleep, but we wouldn't want to lose out on stack overflow protection to do so.
Couldn't this be achieved with try & catch?
If you are referring to the original suggestion, Kozuma, then I'm not sure.
An infinite loop causes problems only if we didn't expect it to be infinite, and the infinite recursion is triggered by a particular use case we didn't account for and didn't detect during testing.
Try/catch doesn't appear to even catch the infinite loop runtime.
Indeed try/catch does not catch this. The runtime message is actually not processed through the same method, because unlike a regular runtime error it doesn't end the proc.