Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Make the timer event list in sorted order && Fix for issue #633 #654
I can't split the commits into two pull requests, so put them in a single one.
What the first commit does:
Insert the timer event in sorted order, so it's O(1) to get the nearest timer. Insert and delete a timer is O(N).
And the second:
When system time changes back, the timer will not worker properly hence some core functionality of redis will stop working(e.g. replication, bgsave, etc). The patch saves the previous time and when a system clock skew is detected, it will force expire all timers.
See issue #633 for details of the second commit.
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
The above 5 lines of code are probably not useful, because if eventLoop->timeEventHead is NULL, what happens in the next lines is:
So I guess we can remove this code. Makes sense?
I think commit 4274554 is fine and fixes an actual issue so I want to merge it into 2.6 and unstable.
For commit 941825c things are a bit different, basically from the point of view of Redis that has just one timer it does not offer a real advantage, but my add bugs, I found one for instance proof reading the code: the processTimeEvents() function no longer checks for maxid to process (plus restarting from head again if an event is processed), so if an event fires a callback that alters the list (for instance deleting its own time event, the one that fired the procedure) bad things may happen.
At this point I'm cherry-picking commit 4274554 and moving the milestone of this issue to 2.8 so that we can have time to reimplement the O(1) thing with a skiplist and with more checks to make sure everything will be safe.
Another note, this time about commit 4274554, currently the code is thread safe, so I would like to retain this capability and add a last_sec field in the eventloop structure itself so that every event loop has its own private field. In this way it is possible to use the library with multiple event loops from multiple threads.