Patches item #1690578, was opened at 2007-03-29 07:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690578&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: None Status: Open Resolution: None >Priority: 1 Private: No Submitted By: xiaowen (xiaowen) Assigned to: Nobody/Anonymous (nobody) Summary: Don't block on Queue get/put when time is moved back Initial Comment: When Queue get and put methods are called with a timeout, they effectively store the end time and might block until that end time is reached. This breaks if the system time is moved back. The attached patch breaks out of the wait if it detects the time has been moved back. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-11 12:34 Message: Logged In: YES user_id=80475 Originator: NO I was recommending against "fixing" this everywhere. See related comments on pathc #1607149: Condition.wait timeout fails on clock change. Recommend closing this patch. The problem is not the responsibility of every client accessing time() or sleep(). The clients do not have enough information to reliably detect changes and to know how much the time changed. Even if those are known, it is not clear that adjusting the timeout is the always right thing to do. Also, this "problem" is somewhat obscure. Lowering the priority to 1 and recommending that the patch (and all like it) be rejected. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-04-09 16:21 Message: Logged In: YES user_id=341410 Originator: NO I agree that it would be better to fix this everywhere we can. But unless we start replacing the generic versions of everything that uses a timeout for platform-specific versions (that have guarantees regarding specified timeouts and notifications), about all we can really do is to patch each item as we go along. I suppose a good first step would be to write a generic "wait for" function that would sit in threading, _Condition.wait() is a good start. From there, one could write platform variants (Windows could use WaitForSingleObject, etc.) that don't change the end time, calling them on a platform if they exist. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2007-04-09 15:51 Message: Logged In: YES user_id=80475 Originator: NO When a system moves time backwards, it breaks a host of invariants, not just the one in the queue module. I would not want some variant of this code used everywhere time differences are computed. Another thought is that the use case is somewhat exceptional and that the solution (readjusting endtime) isn't necessarily the right thing to do. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-04-09 15:36 Message: Logged In: YES user_id=341410 Originator: NO I am unsure if this is a sufficient or correct patch, but the functionality is desirable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1690578&group_id=5470 _______________________________________________ Patches mailing list Patches@python.org http://mail.python.org/mailman/listinfo/patches
