time.time() strangeness

[Nitro]

Hello,

today I encountered a very odd situation. I am on Windows Vista and using
Python 2.5.2. Here's a code snippet to illustrate my problem:

# uncomment the next line to trigger the problem
# myExtensionModu le.CreateDirect 3D9Device()
import time
for i in range(0,100):
print time.time()

With the line commented time.time() returns a changing value which is what
I expect. However, when I uncomment it and create a Direct3D9 Device
[1][2] it keeps printing the very same number over and over! In my project
I am using twisted which uses time.time() to schedule all calls. Since
time.time() is completely screwed the whole application breaks.
I took a look at [3], but I can't see any obivous way how this all
interacts. Specifically I am not sure which API time.time() uses
internally (timeGetTime maybe?). Knowing this could probably help me debug
more. I feel like time.time() should not break (unless the vid card
driver/directx has a major bug). Any idea what might be happening here?
Replacing time.time() with time.clock() in twisted.python. runtime makes
the problem disappear. I guess because it uses QueryPerformanc eCounter.

Thanks for your time,
-Matthias

References:
[1] http://msdn2.microsoft.com/en-us/lib...27(VS.85).aspx
[2] http://msdn2.microsoft.com/en-us/lib...27(VS.85).aspx
[3]

http://svn.python.org/view/python/trunk/Modules/timemodule.c?rev=59678&view=markup

[Paul Rubin]

Re: time.time() strangeness

Nitro <nitro@dr-code.orgwrites:

With the line commented time.time() returns a changing value which is
what I expect. However, when I uncomment it and create a Direct3D9
Device [1][2] it keeps printing the very same number over and over!

The granularity of time.time can be quite large, maybe as much
as 1 second in some systems. Also, if the user can set the time,
the output might not be monotone. They might set the clock backwards
if it has drifted ahead, or something like that. Better to use an
explicit counter if you need a monotonically increasing sequence.