[Twisted-Python] callLater(0) is A BIG LIE
bob at redivi.com
Mon Nov 1 14:34:08 EST 2004
On Nov 1, 2004, at 13:27, Phillip J. Eby wrote:
> At 12:51 PM 11/1/04 -0500, Bob Ippolito wrote:
>> Actually callLater(0, ....) was an edge case up until recently (I
>> hope it got fixed?) where it DID run in the current iteration.. a
>> timer that fired another timer with 0 delay would cause the timer
>> processing to never finish, so IO wouldn't happen anymore.
>> Of course, everyone expected it to mean "call function f in the next
>> reactor iteration".. but it didn't :)
> Right; I'm arguing that even in a "sane" scheduler it *doesn't* mean
> that, on a sufficiently fast machine with a sufficiently
> low-granularity clock. For example, on Windows, time.time() has
> sufficiently low resolution that this can happen.
> However, regardless of clock resolution, using a *non-zero* value for
> callLater, regardless of how small the value is, is sufficient to
> ensure that the item is run in the next iteration. This should be
> true for any sane scheduler (i.e., one that can't enter a state of
> perpetual I/O starvation).
Well if you guarantee that any timer fired during the timer-processing
phase of the runloop will not get processed until the next runloop
iteration, then you shouldn't have a problem with I/O starvation or
low-granularity clocks... just like you need to guarantee that any
event generator (i.e. observed file descriptor) is only allowed to make
noise once per runloop.
More information about the Twisted-Python