I just glanced at the diffs on that change and it looks like it is releasing the global timer lock and then grabbing the lock on the individual timer. Doesn't that create a race condition where the timer can be deleted in between releasing the global lock and grabbing the local? Shouldn't that order be reversed?
Alex Ionescu wrote:
hbirr@svn.reactos.com wrote:
- Fixed ExTimerRundown.
Hi,
Can you please explain some of your changes? You have introduced several changes that I don't understand, such as cancelling the timer's APC without actually making sure that it has an APC associated, as well as slowing down the path and forcing additionnal locking of the DB lock by using KeCancelTimer (which also uselessly checks if the timer is inserted -- we are sure it already is).
Apart from that, thanks for fixing the silly bugs!
Best regards, Alex Ionescu