Problem with time.time() standing still

Bob Cowdery bob at bobcowdery.plus.com
Sun May 6 04:18:23 EDT 2012


On 05/05/2012 23:05, Cameron Simpson wrote:
> On 05May2012 20:33, Bob Cowdery <bob at bobcowdery.plus.com> wrote:
> | I've written a straight forward extension that wraps a vendors SDK for a
> | video capture card. All works well except that in the Python thread on
> | which I call the extension, after certain calls that I believe are using
> | DirectShow,  time stands still. The thread returns fine as the extension
> | does its stuff in its own threads. In all other respects the Python
> | thread seems unaffected but 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. I also tried datetime and that had
the same behaviour.
>
> | 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. The video
SDK is Windows only. 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. 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. I'd dearly
love to know what's going on here. I thought about extracting the time
module, building it, calling it something else and seeing if it behaves
the same. All time consuming unfortunately when I have a deadline.
>
> Cheers,




More information about the Python-list mailing list