[Twisted-Python] Accurate delays in callLater

Jp Calderone exarkun at divmod.com
Thu Jun 23 17:05:17 EDT 2005

On Thu, 23 Jun 2005 16:36:00 -0400, Norm Petterson <njp at njp.us> wrote:
>Jp Calderone wrote:
>>On Thu, 23 Jun 2005 12:34:41 -0700, Ian Duggan <ian at ianduggan.net> wrote:
>>>On Thursday 23 June 2005 11:27, Norm Petterson wrote:
>>>>If the slippage were unacceptable, I'd try raising process priority
>>>>before anything else...
>>>Another idea is to do the bookkeeping yourself.
>>I'd be interested to hear more details about cases where LoopingCall does 
>>allow slippage.  As far as I know, there is no room for improvement here: 
>>the only thing that could cause it to slip is if the system clock were not 
>>maintaining time correctly, and in that case I believe you are pretty much 
>>screwed on anything time related (okay, maybe not, I guess you could have 
>>an NTP implementation and schedule things against that, rather than the 
>>system clock...)
>In my case, for instance, 86400 repeated 1 second TimerService calls might 
>take a few minutes more than precisely 24 hours (which is acceptable, so I 
>haven't checked further). I am guessing that something outside of Twisted, 
>running at a higher process priority  occasionally ties up the machine long 
>enough to miss at least one scheduled cycle, possibly even more than one. 
>AFAICT LoopingCall doesn't make any attempt to compensate for entirely 
>missed (i.e., catastrophically missed) cycles, only for the minor slippage 
>that might otherwise lead to gradually missed ones. Right?
>Not a Twisted issue; hence recommending bumping process priority.

Aha, this makes perfect sense.  It's a different kind of slippage than what I thought you were talking about.


More information about the Twisted-Python mailing list