On 20/02/12 20:32, Glyph wrote: > Well, it depends on how you define a "bug". LoopingCall's internal > state remains consistent, but if you set your clock backwards, > LoopingCall won't fire your callback again until the system clock > catches up to where it previously was. Any new LoopingCalls that are > created will work fine, although they will probably report an > incorrect skipCount if you set the clock forward again.
Ah. This doesn't jump out from the original ticket text; the way I read the text, it implies the LoopingCall stops being *scheduled* if the clock goes backwards. If I'm understanding it correctly, the problem is actually that the callLater for the next run doesn't fire when expected, because it's scheduled in the "pre-change" timeframe (now the future). As opposed to being anything in the LoopingCall code? I realise this is tricky to solve, but I'll note it's not impossible for really REALLY big clock skews to happen. For example: recently we had a server kernel panic and need a cold reboot. The machine booted and read it's time from the CMOS clock, which was way WAY out. A minute or two after the machine had booted, NTP slewed the clock back by months... Fortunately this box doesn't run any Twisted code that a) starts on boot and b) makes use of LoopingCall. [I know this is horrible, but a lot of Unix distros don't sync system to hardware clock periodically - usually on shutdown only - and a lot of distros don't block boot until NTP has set the clock] I realise it's an edge case; but at the very least, it is probably worth updating the LoopingCall/IReactorTime.callLater documentation to make this behaviour clear, because I certainly didn't appreciate this could occur. It's pretty obvious in hindsight, though. _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
