[Twisted-Python] callLater(0) is A BIG LIE

[Bob Ippolito]

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.

-bob