[Twisted-Python] accurate periodic call

Phil Mayers p.mayers at imperial.ac.uk
Tue Feb 21 06:05:33 EST 2012


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.



More information about the Twisted-Python mailing list