Addendum to TriggerRemoveAction stopping the thread

This is a follow on from Blade's discovery (or rediscovery) of the fact that TriggerRemoveAction stops a trigger's thread instantly (Original thread here). Unmi didn't believe this, so he tested and got results that didn't agree with Blade's findings (Second page of this thread).

After that, I took up testing to find out what was going on. It turns out that TriggerRemoveAction will stop a trigger's thread as soon as it hits the next pause in execution (ie. TriggerSleepAction). Blade didn't pick this up, because he used TriggerSleepAction in his test.

The end conclusion of this is that TriggerRemoveAction is safe to use in trigger cleaning up itself (assuming you don't use waits for odd reasons) without the need to create a new thread. Don't we all love Blizzard?

TriggerSleepAction - IS THE GREATES SHIT IN JASS ! for exapmle in dead thread it will put every time if called the last free handle index to the stack so the stack of handle indexes will look out like this...
....1050345,1050325,1050305,1050305,1050305,1050305,1050305,1050305

and all new created objects will get the 1050305 hadnle up to the stack will be freed to "normal" indexes.

I thought this was obvious? I remember reading another thread that stated about sleeping threads getting destroyed by TriggerRemoveAction.

The last thread I even recall seeing referring to this was Blade's one which I linked to. At the very least it is useful for people who didn't see this 'other thread', because it eliminates the confusion about it.

Does it do this for a trigger where no stack is passed (ie: the event does not give anything to call)?

it's not that simple as just a sleep. Sometimes one sleep isn't enough. Real bizarre.

O.o? When I tested a single sleep worked fine. Can you show an example where it required more than one?