[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.
Jp
More information about the Twisted-Python
mailing list