[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