Zugg Software :: View topic - [3.06] Feature Request: Enhanced Loop Detection and Recovery

Posted: Fri May 01, 2009 3:49 am

While you do have loop detection and it has worked for me in certain circumstances, I think there is room for improvement.

For example, if I try to execute:

#while (1) {}

My only recourse is to kill Cmud through the task manager. I try to use #while statements as little as possible because despite my best efforts it is so easy to create a never-ending while loop. But there are times when I need a while statement for something that won't work any other way. Whenever I mess up and it goes on an endless loop there is no way I can recover gracefully from it.

I'd love to see something alone these lines:

1) Separate the threads that control turning off triggers/parsing so that if I get in an endless loop I can click them and turn off triggers/parsing.
2) Or allow a key combination or macro of some sorts to turn off execution so I can go in and fix the loop before restoring execution.
3) Or improve the loop detection so it encompases endless while loops.

I'm not sure if any of those are feasible, but I'd really like a better way to recover from endless loops besides killing Cmud.

Posted: Fri May 01, 2009 5:24 pm

If you do this on the command line, you should be able to press the ESC key to kill any running threads. If it's in a background script, you can use the #THREAD command to see what thread number it is, and then use the #STOP nnn command to kill the thread.

Unfortunately, there isn't any good way to detect such a loop. There are even times when doing a "#WHILE (1) {whatever}" loop is desirable if another script is controlling the thread with the loop.

In any case, give the ESC key a try the next time it happens. Works for me here.

Posted: Fri May 01, 2009 6:28 pm

The ESC key works fine for running from the prompt or for running an alias, however, that's not normally where I get myself into trouble.

When "#while (1) {}" is executed by a trigger I can't use the #thread command because the command line is locked up and unresponsive. That is what I was referring to when asking if the threads could be separated (above) so that some type of recovery can be done to recover from the situation. If there was some part of Cmud that was still responsive during this event I might be able to shut down the run-away process somehow.

Are you saying that you have been able to use the #thread command to halt a runaway "#while (1) {}" executed by a trigger?

Posted: Sat May 02, 2009 1:40 am

I find in a loop, that I have no control over CMUD. Its normally a trigger loop for me though, for example, I made a silly trigger to do

stand
claw target
claw target

when it received the line "You must stand before you do that."

Since I could not stand, sending those three commands caused the mud to send me that line another 3 times. It grew pretty quickly out of control, but I could not enter anything at the command line, hit esc or mouse-click triggers off. Closing CMUD through the task manager was the only way.

I know it is a different situation to ReedN, and I know that ultimately the answer is "think before you create triggers," but I just wanted to say that I too find the command line unresponsive during loops.