null timers?

[edo494]

Well, I made a spell using timer(s) and i nulled them after starting.
But recently I've read this:

no problem
Note, that destroying timers and then setting its variable to null can cause a similar handle stack corruption bug. You can avoid this by using timer recycling, for example TimerUtils (or by never setting timer variables to null, taking insignificant leaks into account).

So if I do this:

function A takes nothing returns nothing
    local timer t = GetExpiredTimer()
    //some other stuff here
    set t = null
endfunction

function B takes nothing returns nothing
    local timer t = CreateTimer()
    call TimerStart(t, 1., false, function A)
    set t = null
endfunction

Is both t = null OK or shouldn't I null timers?

 

[Mr_Bean]

From what I understand, they are saying that destroying timers is bad, not nulling the timer variables.

Your script is okay, but the timer is leaked (it is not destroyed or nulled). I recommend using TimerUtils to recycle timers, as mentioned in the quote.

 

[PurgeandFire]

If you worry about the handle stack corruption then you can destroy the timer but not null it.

I've never encountered that bug that way, although I am sure it exists. However, it most likely requires some specific functions to be called like the handle stack corruption that comes with trigger sleep action.

But as the quote and mrbean said, you can always just use a timer recycling system and not worry about it.

 

[edo494]

So I understand I should use TimerUtils, but if i want it in vanilla JASS? will

function A takes nothing returns nothing
    local timer t = GetExpiredTimer()
    //some other stuff here
    call DestroyTimer(t)
    set t = null
endfunction

function B takes nothing returns nothing
    local timer t = CreateTimer()
    call TimerStart(t, 1., false, function A)
    set t = null
endfunction

may cause bugs?(as the quote states)

 

[Magtheridon96]

The above script should be safe from Handle Stack corruption
Handle Stack corruption only occurs in rare cases, trust me.

I take advantage of handle stack corruption to get access to unit shadows in-game.
It's really cool actually ;3

 

[Dr Super Good]

Learn the cause of why people are nulling handles.

 

[edo494]

well, i know that nulling recycles them = no memory leaks but well i wasn't sure if I should do it. Now I know

 

[Troll-Brain]

The above script should be safe from Handle Stack corruption
Handle Stack corruption only occurs in rare cases, trust me.

I take advantage of handle stack corruption to get access to unit shadows in-game.
It's really cool actually ;3

Well it's just because images, texttags and maybe some other handles that can safely be created in a local block are not handled in the same way.
The id is recycled once the handle has been destroyed, no matter if some variable still points on it or not. (at least they are not concerned by the "null" bug )

This is an example of handle stack corruption (if it's still not fixed)

 

[Magtheridon96]

What!?
BLASPHEMY.

 

[Troll-Brain]

What!?
BLASPHEMY.

Care to elaborate ?

 

[Magtheridon96]

This just shows me how bugged JASS is even more.
I mean, CreateGroup() == CreateGroup() can return true!?
This is madness ;_;

 

[Dr Super Good]

It involves the garbage collector having a reference counter leak. Objects increment the reference counter when referenced but if the local that references them is left to expire it does not dereference them. Not all objects are prone to that kind of leak as objects like Players do not get garbage collected (they are constants).

 

[mckill2009]

This is madness ;_;

no, this is BLASPHEMY from 300 Spartans XD...

Not destroying timers always leaks, TimerUtils always creates timer handles if the previous
timercreated is still in use therefore creating another timer, which causes another memory allocation,
although not really a big deal but what do you think of 256 or more timers created at map initialization
and just recycle it?...

 

[Troll-Brain]

Anyway i suppose that's what you earn with such shitty code.
I would never use a double TSA after destroying the trigger.
I would destroy it and probably use other code below but without any wait between them.

 

[Magtheridon96]

I agree.
There are 0 uses for 2 waits in a row.
0 I tell you.

 

[Deaod]

Except for PolledWait, which doesnt get fucked up when a player starts lagging. People actually do this.

The one rule for destroying triggers is: DONT DO IT.
Theres hardly a need to anyway. Triggers dont leak much.

 

[Magtheridon96]

Oh. That.
Yeah, well.

 

[edo494]

can I ask what PolledWait and destroying triggers has to do with Timers?

 

[Magtheridon96]

Nothing :3

edit
Other than the fact that destroying triggers causes handle stack corruption if done incorrectly, and I think timers do the same.
Recycle your timers my friend.

 

[Dr Super Good]

It is generally a good idea to recycle objects. The practice is called "Green Coding" and can actually make code execute faster in real programs due to the reduction of memory allocation and de-allocation overhead.

That said, it is a good idea to implement it in a sane way. Be aware of possible spike conditions which could lead to excessive permanent allocation unless handled correctly. Consider using bounded structures which will only start destroying objects when full, giving enough time for objects to be destroyed safely.

Green Coding is useless if every single system keeps their own object buffer. In WC3 object buffers should be global and used in all systems that require their functionality. In Real programming it can sometimes be a good idea to use thread based object buffers to avoid synchronization overhead although such buffers should logically be smaller than global ones.