 |
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
 Posted: Fri Nov 30, 2007 5:45 pm
Opinion about multiple Alarm instances
|
One of the issues that has been causing problems for some people is that CMUD is allowing multiple copies of the same alarm to be running at the same time. For example, if you have a recurring alarm like this:
| Code: |
| #ALARM *0.5 {do something slow here} |
Then you can end up with an overwhelming number of these alarms all running at the same time if the alarm code takes longer than 0.5 seconds to execute. For example, in the middle of executing the alarm, the alarm time expires and fires again. and again. and again.
I can see where this is going to cause a lot of problems. So, does it really make sense to allow the same alarm to keep firing while it is still executing?
This is similar to a change made recently with Expression triggers. In 2.13 I changed CMUD so that an Expression trigger doesn't fire if it is already in the middle of running. Does the same thing need to be done for Alarms?
I don't really remember how this worked in zMUD, but I think that if you had a slow alarm in zMUD it wouldn't re-enable the alarm until after the previous instance was completed. Maybe CMUD needs to do something similar?
Another way to ask this question: If you have a trigger like that above with *0.5 as the time pattern, is it really important that the alarm fire every half second no matter what? Or can the interval be longer if your alarm is slower? Should the alarm run 0.5 seconds after the previous alarm was *started* or 0.5 seconds after the previous alarm was *finished*?? |
|
|
|
|
Malach
Apprentice
Joined: 03 Nov 2007
Posts: 132
|
Posted: Fri Nov 30, 2007 5:55 pm
|
My understanding of how it worked was that the alarm would fire .5 seconds after the first alarm was finished as usually the interval is in place as a control for whatever settings are being executed inside the alarm, not the alarm itself.
|
|
_________________
Intel Core2 Quad CPU @ 2.4 GHZ with Windows Vista Home Premium and 2 GB Ram |
 |
|
|
ardwick
Novice
Joined: 31 May 2007
Posts: 32
|
Posted: Fri Nov 30, 2007 6:11 pm
|
| Malach wrote: |
| My understanding of how it worked was that the alarm would fire .5 seconds after the first alarm was finished as usually the interval is in place as a control for whatever settings are being executed inside the alarm, not the alarm itself. |
Agree |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5187
|
Posted: Fri Nov 30, 2007 6:51 pm
|
I would have to agree with the time interval should start counting when the alarm is finished. The alarm you are describing could be rewritten as a thread code this way:
| Code: |
| #THREAD SlowAlarm {#WHILE (1) {#WAIT 500;do something slow here}} |
When you examine how that thread would work you find that the timer interval is used initially from first activation, then starts its count again when the code actually finishes. It seems the most consistent behavior as long as the timing is tied to the specific alarm. I don't think anyone wants the slow alarm to kill the fast alarm.
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Arminas
Wizard
Joined: 11 Jul 2002
Posts: 1265
Location: USA
|
Posted: Fri Nov 30, 2007 8:36 pm
|
0.5 seconds after the previous alarm was *finished*.
|
|
_________________
Arminas, The Invisible horseman
Windows 7 Pro 32 bit
AMD 64 X2 2.51 Dual Core, 2 GB of Ram |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Fri Nov 30, 2007 10:02 pm
|
OK, sounds like consensus, and I agree with the result. I will modify this in v2.14 and see how that works.
Also, for global alarms, the alarm will fire again *after* the *last* window has execute the script. In other words, the alarm is considered "finished" only after all windows have executed the script for it. |
|
|
|
|
|
|
|
