Patches item #1607149, was opened at 2006-12-01 14:32 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1607149&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: Library (Lib) Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: BC (hashstat) Assigned to: Nobody/Anonymous (nobody) Summary: bug# 1607041: Condition.wait timeout fails on clock change Initial Comment: This patch if for bug# 1607041. If the system clock is adjusted after Condition.wait is called with a timeout, the timeout does not expire as expected. This appears to be due to the threading.Condition class using the system clock to calculate the timeout expiration without taking system clock changes into account. No matter what timeout is used, setting the system clock ahead reduces or eliminates the wait while setting the system clock back increases the wait. So if the clock is set back one hour in the middle of a 1 microsecond wait (c.wait(1)), wait will return in an hour and 1 microsecond rather than after 1 microsecond. This patch modifies the Condition classes wait method to check for variations in the clock between calls to sleep and ajust for abnormalities. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-02-10 10:02 Message: Logged In: YES user_id=341410 Originator: NO Really, it would be better if time.sleep was based off of a monotonic clock, then everything could use the single working API, and we wouldn't need to monkey-patch everything that uses sleep. Unfortunately, due to the insanity that is the underlying Windows platform, the bios clock is set to local time and is converted to UTC (which is then used natively by NT). There is a work-around involving setting the system clock to UTC and setting a registry setting, but it doesn't always work, can cause 100% CPU usage during DST changes, and doesn't propagate time changes from NT to the underlying clock. http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html An alternate (or additional option) is to just disable DST changes, manually adjust times as necessary (or using a script that runs only at boot), and never run any software while adjusting the time. http://www.pcreview.co.uk/forums/thread-531048-2.php Considering the recent changes to DST, the latter link is probably more applicable. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2006-12-02 23:11 Message: Logged In: YES user_id=21627 Originator: NO It would be better if this was based on a monotonic clock if available on the system (such as the POSIX CLOCK_MONOTONIC argument to clock_gettime). "Guessing" jumps in the time is inherently unreliable; in your code, you won't notice changes that involve less than 10s. Notice that the same problem exists for Thread.join; it would be good if they were fixed together. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1607149&group_id=5470 _______________________________________________ Patches mailing list Patches@python.org http://mail.python.org/mailman/listinfo/patches
