[Twisted-Python] A problem with runUntilCurrent
Phillip J. Eby
pje at telecommunity.com
Mon May 17 11:46:35 EDT 2004
At 04:04 PM 5/17/04 +0100, Bill la Forge wrote:
>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.
More information about the Twisted-Python