Fixed bug where behavior of new timers added during iteration through timer handles was indeterminate.
On master, consider that while iterating through self.functions, we use pairs.
-- timer.lua on master
for handle in pairs(self.functions) do
-- <update handle...>
end
So, if we have a timer that does something like this:
local timerOne = Timer.after(1, function()
local timerTwo = Timer.after(1, function() print('does something else') end)
end
Now, if we run `Timer.update(1), there are two possibilities.
A. timerTwo is updated later.
timerOne will finish.
timerOne will execute and create timerTwo, it will be added to somewhere considered "before" timerOne in pairs(self.functions).
timerTwo will not be updated in this call of Timer.update.
B. timerTwo is updated immediately.
timerOne will finish.
timerOne will execute and create timerTwo, it will be added to somewhere considered "after" timerOne in pairs(self.functions).
timerTwo will be updated in this call of Timer.update, thus printing "does something else" immediately.
To fix this issue, before starting to iterate through self.functions, we gather together all of the timer handles which currently exist, so that new timers will not be updated until the next call of Timer.update().
Fixed bug where behavior of new timers added during iteration through timer handles was indeterminate.
On master, consider that while iterating through
self.functions
, we usepairs
.So, if we have a timer that does something like this:
Now, if we run `Timer.update(1), there are two possibilities.
A. timerTwo is updated later.
pairs(self.functions)
.Timer.update
.B. timerTwo is updated immediately.
pairs(self.functions)
.Timer.update
, thus printing "does something else" immediately.To fix this issue, before starting to iterate through
self.functions
, we gather together all of the timer handles which currently exist, so that new timers will not be updated until the next call ofTimer.update()
.