Problem with time.time() standing still

[Bob Cowdery]

On 06/05/2012 09:49, Cameron Simpson wrote:
> On 06May2012 09:18, Bob Cowdery <bob at bobcowdery.plus.com> wrote:
> | On 05/05/2012 23:05, Cameron Simpson wrote:
> | > On 05May2012 20:33, Bob Cowdery <bob at bobcowdery.plus.com> wrote:
> | > | [...] calls to time.time() always return the same
> | > | time which is usually several seconds in the past or future and always
> | > | has no fractional part.
> | >
> | > Thought #1: you are calling time.time() and haven't unfortunately
> | > renamed it? (I doubt this scenario, though the lack of fractional part
> | > is interesting.)
> |
> | Not sure what you mean by renamed it.
>
> Like this:
>
>   from time import time
>   [...]
>   time = some_unfortunate_other_function
>   [...]
>   now = time()  # calls wrong function
>
> It seems unlikely, but possible.
>
> | I also tried datetime and that had
> | the same behaviour.
>
> Makes my suggestion even less likely unless the time module itself gets
> monkeypatched (i.e. "time.time = bad_function" somewhere).
I don't think the function is subverted unless there is some way inside
the vendor SDK or even DirectShow (the SDK uses this as a COM object)
which can somehow hijack it. It does catch up every few minutes so there
has to be a clue there. 
> | > | If I leave it long enough time will suddently
> | > | jump forward after a few minutes, then again after a few minutes more.
> | > | 
> | > | I've never encountered this behaviour before and can't understand what
> | > | on earth is going on. If I call the 'C' time() function just the other
> | > | side of my call to the extension the time is ticking along fine. It's
> | > | just the one Python thread that is affected.
> | > [...]
> | >
> | > Thought #2: On a UNIX system I'd be running the process under strace (or
> | > dtrace or ktrace depending on flavour) to see what actual OS system calls are
> | > being made during this behaviour. Is this feasible for you?
> |
> | I'm on Windows for this particular part of the application.
>
> I'd guessed so. I've no Windows programming background; I was wondering
> if there was something like this you had to hand on windows.
Maybe, but not that I know of.
> | [...] But debugging into this is probably the only way. I
> | looked at the built-in time module. As far as I can tell it just calls
> | the underlying C time() function as an extension. This is more
> | mystifying as that is pretty much what I'm doing by checking the time in
> | my own extension module where it ticks along fine.
>
> Hmm. A C extension I presume? How about writing a little pure Python
> thread to call time.time(), and spin it off parallel to the rest of the
> app; does it also get bad time.time() behaviour?
I've tried that. It's only the Python thread (or Python main thread)
that calls the extension that behaves like this. Other Python threads
tick along fine with the correct time including a fractional part.
> | I have another
> | scenario using a different part of their SDK where the time does still
> | tick but the fractional part is frozen, not 0 but frozen.
>
> Curiouser and curiouser.
Indeed. Away now but battle will resume on Tuesday.

Bob