[Patches] [ python-Patches-1690578 ] Don't block on Queue get/put when time is moved back

[SourceForge.net]

Patches item #1690578, was opened at 2007-03-29 14:32
Message generated for change (Comment added) made by loewis
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: Closed
>Resolution: Rejected
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: Martin v. Löwis (loewis)
Date: 2007-04-15 09:28

Message:
Logged In: YES 
user_id=21627
Originator: NO

Rejecting this patch for the same reason #1607149 was rejected.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-11 19: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 23: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 22: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 22: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