Zugg Software :: View topic - freezing of main window when function called

Beginner Joined: 06 Feb 2012 Posts: 11 Location: Phoenix

Hi, I recently redesigned some of my code so that I can incorporate new areas without duplicating the same function over and over by use of functions. This is my first time using functions however I"m noticing that when the function is called output to the buffer is frozen so to speak until I click the buffer with my mouse. This is odd because even though the buffer seems to be frozen everything is still running in the background just fine. Has anyone experienced this before or know of a way to prevent it? Here is my function that is being called

EDIT: Code removed as problem was solved without it.

Posted: Wed Feb 08, 2012 9:49 pm

try sticking a #WAIT 0 at the start of any script that may potentially be rather intensive on CMUD
That effectively sticks it in a separate thread so as not to make the system appear locked up

Beginner Joined: 06 Feb 2012 Posts: 11 Location: Phoenix

Beginner Joined: 06 Feb 2012 Posts: 11 Location: Phoenix

So after a while of using the #WAIT for new threads I've noticed some weird bugs popping up in my scripts. Basically the scripts just start doing random things like not triggering when they are supposed to, not setting variables, or not unsetting variables which would ultimately cause my if statements to trigger at the wrong times. The behavior overall is very random and has no rhyme or reason. I actually spent a good while diagnosing the problem before I thought to remove the #WAIT lines because I had added other changes to my scripts before I noticed the problem. Anyway the problem is gone now that I removed #WAIT but I'm wondering what could have caused that and if there was a way to fix it. I really enjoyed having my scripts run in their own threads as it helped keep things running smoothly.

Wizard Joined: 22 Mar 2007 Posts: 2320

One of the effects of using #WAIT is that the entire script gets executed in a separate background thread instead of the main thread. In fact, this was why Shalimar suggested using it. The main thread also handles all parsing of text from the mud, parsing and execution of commands from the command line, and printing text in the display window. Your long scripts were preventing all of that from happening until the scripts were finished. Putting the long scripts in separate threads solved that problem, but it has to be done carefully to avoid new difficulties.

It is likely that many of your scripts depend on output from each other, or use the same variables as each other. When all the scripts are executed in the main thread, you can guarantee that one script will not begin until the previous script has ended. When you put things in separate threads, you no longer have that guarantee. Suppose, for instance, that you have a trigger that captures a name on one line and sets a variable @target to that name. Then another trigger fires on the next line which executes a spell at @target. If both triggers execute in the main thread, then first line is parsed from the mud, the first trigger fires, runs, and finishes, then the second line is parsed, fires the second trigger, which executes properly. But what if the first trigger executes in a separate thread? The first line is parsed, the first trigger fires, and begins executing in a new thread. The main thread then parses the second line without waiting for the first thread to finish. The second trigger might end up executing before the first trigger has set the @target variable.

Another problem that can occur is if two threads try to set the value of the same variable at the same time. This leads to a conflict, and possibly an error or other unexpected behavior.

If you need to use #WAIT or similar commands which place the script in the background, you must evaluate those scripts carefully. See how they interact with other scripts, through common variables, or executing aliases, or text output. Figure out the dependencies between scripts, and how they might clash if one script finishes before the other. You may have to redesign your scripts to avoid such dependencies, or to make sure that certain things execute in the right order. You may have to use #SECTION to protect certain pieces of code to make sure no other scripts can change variables while that piece is running.

Writing code with threads can be difficult. Some commands you may want to learn are #WAITFOR, #WAITSIGNAL, #WAITTHREAD, #THREAD, #SIGNAL, and all the documentation on threads.

Beginner Joined: 06 Feb 2012 Posts: 11 Location: Phoenix

Rahab, thank you for your reply. I will look into the commands you provided to see if I can better optimize my script.