[Twisted-Python] A problem with runUntilCurrent

[Phillip J. Eby]

At 04:04 PM 5/17/04 +0100, Bill la Forge wrote:
>Itamar,
>
>This is also problematic. What this code does is limit the number of
>calls that will be made by runUntilCurrent. However, if there's code
>that does a callLater with a delay of 0, it will always execute that.

What I don't understand is why that should be the case.  A delay of zero 
should equal the *current time* plus zero.  The 'now' variable, however, is 
fixed at the time when 'runUntilCurrent()' is called.  Therefore, as soon 
as any time has elapsed (i.e. time() advances one quantum), a newly 
scheduled callLater(0,) must be scheduled for a time that is *after* 'now', 
and therefore ineligible for call within the loop.

(I'm particularly puzzled, therefore, by the part of Itamar's patch that 
sets the scheduled time to zero for callLater(0,).)

The real problem here, if any, is likely the use of a low-resolution time() 
value.  On Windows, for example, the tick granularity is like 1/18th of a 
second, so a callLater(0,) loop will consume a huge amount of time.  On 
Windows, a scheduler should probably use the high-res clock() rather than 
the low-res time() in order to work around this, which will ensure that 
nothing scheduled during a 'runUntilCurrent()' call will be executed until 
the *next* 'runUntilCurrent()' call.