Destroying/Recycling triggers/handles

[the Immortal]

Could someone kind enough explain to me or point me to a resource why dynamic/local triggers are considered bad (considering they are destroyed correctly, including ta, attached data, etc, etc..), and in similarly the same question about timers/groups?

Only for the speed gain? (*cough* talking about speed in a 7-years-old engine)
Or 'cause of some kind of leaking?
Or what?

So why "the mantra is that dynamic triggers are evil"? What's the gain in dynamically recycling instead of dynamically creating/destroying 'em?

 

[Nestharus]

Well, for one, you cannot recycle triggers with events on them unless you plan on using those same events or the events no longer apply (if you don't mind the tiny memory leaks).


Number 2, the reason destruction of timers and triggers is considered bad by people is because they have a chance to cause handle stack corruption. If you destroy a timer that is still running and you didn't pause it, then when that timer expires, the handle stack will be corrupt as the timer's handle id will have already been released.

The same goes for triggers that run on the next cycle but are not disabled

• DestroyTrigger
• TriggerSleepAction

So if you do proper destruction of them, there is absolutely nothing to worry about. It's just that most people don't do proper destruction and don't read about the causes.

 

[kingkingyyk3]

Always disable trigger and use TriggerClearAction before you destroying it. I used it for ages, no problem for me.

 

[the Immortal]

Thanks both of you. Though I should ask what "triggers that run on the next cycle" actually mean? Triggers running on the same thread (i.e. event)?

Actually for, hmm, 5 years mapmaking, 3 of which in JASS (though with only 2 released JASS-driven maps) I've never had problems with dynamic triggers/timers. It's just that people say 'hey, that creates and destroys triggers on runtime, it's bad!' finally managed to bother me enough

 

[Nestharus]

Games run in a loop. At the end of each cycle of the loop, latent handle ids are released for reuse. When you use timers or TriggerSleepAction, you end up going to the next cycle of the loop =).

 

[Troll-Brain]

TriggerClearActions doesn't remove the leak though.
You can use TriggerRemoveAction but you have to link the action with the trigger.
Someone could make hooks/defines to handle that

Only trigger conditions don't leak.

 

[the Immortal]

@Troll-Brain: aware was of that, though am really against fixing TA leaks on higher level. Real coders do that alone =P

Nonetheless, great thanks for clearing it out. No more pointless overuse of recycling systems tbh.

 

[Troll-Brain]

It was a more a joke than something serious, just use triggerconditions and timers.
EDIT : Your link is funny.

 

[Zwiebelchen]

The minor event memory leak on dynamic triggers doesn't really matter. I never experienced ANY performance drop just because of dynamic triggers. Maybe the drop is there, but you can not 'feel' it even on a 10 hours game.

Also, I never heard that triggeractions leak when the trigger gets destroyed. Are you sure about that? If so, weird, because most of the more advanced coders out there never bothered removing triggeractions upon trigger destruction.

I also never heard of the timer stack corruption thing. Are you sure this is still there? I never had any problems with creating/destroying timers ever.

 

[Nestharus]

The minor event memory leak on dynamic triggers doesn't really matter. I never experienced ANY performance drop just because of dynamic triggers. Maybe the drop is there, but you can not 'feel' it even on a 10 hours game.

Also, I never heard that triggeractions leak when the trigger gets destroyed. Are you sure about that? If so, weird, because most of the more advanced coders out there never bothered removing triggeractions upon trigger destruction.

I also never heard of the timer stack corruption thing. Are you sure this is still there? I never had any problems with creating/destroying timers ever.

of course we're sure -.-... the general wc3 community has known about these things for at least a couple of years.

 

[Zwiebelchen]

of course we're sure -.-... the general wc3 community has known about these things for at least a couple of years.

Can you give me a link or something to prove it? Just because it was there years ago doesn't mean it has to be still there.

 

[Nestharus]

If you knew how the language worked, you'd understand why those are facts... I came to those conclusions without any testing =). I've never tested handle stack corruption on timers or triggers, I just assumed. Other people have tested =).

You just need to learn that games run on a loop. At the end of each cycle of a loop, handle ids are released.


So, if you, for example, have a timer that you destroy but never pause and you null any local variables containing it to free up the handle id at the end of the cycle, then that code will still be in a queue to run when that time has elapsed and that code will reference the handle id that the timer had. This is what causes the handle stack corruption.

It's the same idea with triggers and TriggerSleepAction.


Now, for trigger actions you need to think about the queue for given events again. The memory leaks are because the actions are never removed from that queue. Conditions don't leak because they aren't code values. Only code values are put into these huge queues =P. Look at the CreateTimer and you'll see it takes a code argument, thus it has the exact same issues.

I guess a trigger with TriggerSleepAction that had no actions and only conditions would not cause handle stack corruption. I also don't think TriggerSleepAction would work in that scenario, the thread would just stop as the condition is probably not the origin of the thread (boolexpr vrs code).


Keep in mind that everything I stated above as to the causes of the possible handle stack corruption and leaks is pure postulation.

 

[kingkingyyk3]

High handles' id does not cause lag, Cohadar made a testing for it on wc3c.
TriggerActions does leak, just use TriggerClearActions, if you don't want to set the actions to triggeraction type, before you are destroying them.

Go wc3c.net and find the old threads. It can let you to understand them better.

 

[Troll-Brain]

No ClearTriggerActions only disable the actions but don't destroy them.
You have to use TriggerRemoveAction in order to prevent leaks.

But anyway since triggeractions are just "usefull" for TriggerSleepAction, which is himself totally lame (inaccurate, random and lowest period == almost 0.2 s), just use triggerconditions and timers instead.

I'm not one of them just believe in something that i can test myself.
I always test when i have the possibility.
That's how i've found this leak : http://www.thehelper.net/forums/showthread.php?t=136608

Same for trigger action, you don't have to believe me, you can't test it yourself.
If you really don't know how to do it i can write a test code and explain you how to test it.

 

[kingkingyyk3]

lowest period == almost 0.2 s
Meh

 

[Jesus4Lyf]

Can you give me a link or something to prove it? Just because it was there years ago doesn't mean it has to be still there.

The issue with timers is suspected that it is resolved.
It dates back to when the return bug was abused poorly, and hasn't resurfaced for some time lately. Recycling timers is a practice which, as far as I can see, is superstition these days (and why not do it superstitiously if you've seen a link between destroying timers and handle stack corruption in the past).

 

[Troll-Brain]

lowest period == almost 0.2 s
Meh

Stop whining about that, anyway the result is only valid on a solo game ...