Bugs item #1508864, was opened at 2006-06-19 15:53 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Russell Warren (qopit) Assigned to: Nobody/Anonymous (nobody) Summary: threading.Timer/timeouts break on change of win32 local time Initial Comment: THE ISSUE... --- threading.py imports time.time as _time. On win32 systems, time.time() periodically reads the system time to figure out when to fire an Event. System time can change while waiting for an Event! eg: If the system time is changed while a threading.Timer is pending, the execution time is affected by the time change. eg: set a pending Timer and then change the clock back an hour - this causes your Timer to fire an hour later. This is clearly not desirable. A FIX... --- A fix for this is to use time.clock() on win32 systems instead. Once I found the problem, I currently just fix it by overriding threading._time to be time.clock. Right now I do this in every file that uses threading.Timer. COMMENTS... --- The penalty for this is that there will be a rollover problem eventaully... when the 64-bit performance counter rolls over in 30+ years of continuous pc operation. I'd much rather have this near impossible event than the very likely system time change. This is a general problem I find with the time module and I often have to switch between time() and clock() dependent on operating system, but I only work with win32 and Linux. The issue is that if you want a high resolution and extended rollover counter, it is a different call on each system. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 11:04 Message: Logged In: YES user_id=764593 Logically, these calls should always use clock, since they don't care about the actual time; they only want a baseline for computing elapsed time. Are you saying that they should still use clock-time on linux anyway, because of resolution issues? ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-26 17:59 Message: Logged In: YES user_id=1542586 This is an issue for anything that uses threading.py's _time function. This includes _Condition.wait(), which screws up both Conditions and Events, which then screw up (for example) the core Queue.Queue timeout implementation. threading.Thread.join also uses the _time call, so it could also get screwed by changes to the local time on Win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508864&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
