Bugs item #1508864, was opened at 2006-06-19 19:53 Message generated for change (Comment added) made by jtate 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: Joseph Tate (jtate) Date: 2006-10-09 13:59 Message: Logged In: YES user_id=55276 This is also currently a problem under Linux when the clock is set back. ---------------------------------------------------------------------- Comment By: Russell Warren (qopit) Date: 2006-06-27 20:01 Message: Logged In: YES user_id=1542586 No - just stating that clock() is definitely a better solution for win32. As you say, any system should just use a time-indpendent uptime counter that is as high resolution as possible. I don't know how to get this on linux, but I do seem to recall that, on linux, time() is higher resolution than clock() for some reason. If linux has no performance counter equivalent (isn't it a hardware thing anyway?) I have no clue which is worse... low resolution, or local time change issues. The first is limiting all the time, the second results in wacky and sporadic errors that people might not expect. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-06-27 15: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 21: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
