Problem with time.time() standing still

[Cameron Simpson]

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.)

| 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?

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

A slipping sear could let your M203 grenade launcher fire when you least
expect it.  That would make you quite unpopular in what's left of your unit.
        - page 9 of the August 1993 issue of PS magazine, the US Army's
          preventive maintenance magazine