[issue8799] Hang in lib/test/test_threading.py

STINNER Victor added the comment: This issue discussed different things: * test_threading was unable: I didn't see such failure the last 12 months, and I backported enhancements from master to 2.7, so I consider this issue as fixed * documentation of threading locks: fixed * Except on

[issue8799] Hang in lib/test/test_threading.py

STINNER Victor added the comment: The race condition is not dead, at least in Python 2.7 :-) I backported the change for bpo-30727: "[2.7] test_threading.ConditionTests.test_notify() hangs randomly on Python 2.7". -- ___ Python tracker

[issue8799] Hang in lib/test/test_threading.py

STINNER Victor added the comment: New changeset da6d305b6fcd49ba1224b1fd2131d7648a5be6b9 by Victor Stinner in branch '2.7': bpo-8799: Reduce timing sensitivity of condition test by explicitly (#2320) https://github.com/python/cpython/commit/da6d305b6fcd49ba1224b1fd2131d7648a5be6b9 --

[issue8799] Hang in lib/test/test_threading.py

Changes by STINNER Victor : -- pull_requests: +2371 ___ Python tracker ___ ___

[issue8799] Hang in lib/test/test_threading.py

Roundup Robot added the comment: New changeset 9e48c9538a7f by Kristjan Valur Jonsson in branch 'default': Issue #8799: Reduce timing sensitivity of condition test by explicitly http://hg.python.org/cpython/rev/9e48c9538a7f -- ___ Python tracker

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson added the comment: Here is an updated patch that only adds the necessary safety delay to the main thread. It also explains these in the comments. -- Added file: http://bugs.python.org/file32541/lock_tests.patch ___ Python

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson added the comment: Ah, here we are some 18 months later. Let me have another go. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___

[issue8799] Hang in lib/test/test_threading.py

Changes by A.M. Kuchling li...@amk.ca: -- keywords: -easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___ Python-bugs-list mailing

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson krist...@ccpgames.com added the comment: A few comments: 1) with cv: make_an_item_available() + cv.notify() 2) one of the benefits of wait_for() is that it automates the tricky timekeeping needed if one wants an somewhat accurate timeout, you may want to

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: A few comments: 1) with cv: make_an_item_available() + cv.notify() Did I forget this? Ow. 2) one of the benefits of wait_for() is that it automates the tricky timekeeping needed if one wants an somewhat accurate timeout,

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson krist...@ccpgames.com added the comment: But, once again, the condition may not yet hold true is false. In our current implementation, yes. But it is intentionally left undefined in the specification of the condition variable protocol, for very good reasons. While I'm

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: Le mercredi 11 avril 2012 à 10:50 +, Kristján Valur Jónsson a écrit : But, once again, the condition may not yet hold true is false. In our current implementation, yes. But it is intentionally left undefined in the specification of the

[issue8799] Hang in lib/test/test_threading.py

Charles-François Natali neolo...@free.fr added the comment: [...] Disagreed. Unit tests should definitely protect against the introduction of bugs (willingly or not). And unpredictable behaviour is usually considered a bug. If you think the condition variable specification should be

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: Le mercredi 11 avril 2012 à 11:32 +, Charles-François Natali a écrit : One can imagine, for example, that another implementation (or maybe CPython in a later version) exposes native condition variables on POSIX, instead of emulating them

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: Ok, doc improved in 9d4109af8f3b. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___

[issue8799] Hang in lib/test/test_threading.py

Charles-François Natali neolo...@free.fr added the comment: Ok, doc improved in 9d4109af8f3b. LGTM. Kristján, how about updating your patch to only fix the original problem you spotted (notify() called before wait()), then we can see the remaining parts? --

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson krist...@ccpgames.com added the comment: We shouldn't be testing implementation details. The Condition variables are canonically prone to spurious wakeups and stolen wakeups. The fact that the current implementation doesn't have them shouldn't place that burden on

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: The Condition variables are canonically prone to spurious wakeups and stolen wakeups. No, they aren't. Just because POSIX says they are doesn't mean *our* condition variables are the same. Spurious wakeups are an annoyance, and our

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson krist...@ccpgames.com added the comment: Stolen wakeups are a fact of life though, even in cpython's implementation of condition variables. And for the user of a condition variable the difference is so subtle as to not warrant special mention. This is, btw, not just a

[issue8799] Hang in lib/test/test_threading.py

Charles-François Natali neolo...@free.fr added the comment: The Condition variables are canonically prone to spurious wakeups and stolen wakeups. No, they aren't. Just because POSIX says they are doesn't mean *our* condition variables are the same. Spurious wakeups are an annoyance, and

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: Stolen wakeups are a fact of life though, even in cpython's implementation of condition variables. And for the user of a condition variable the difference is so subtle as to not warrant special mention. I don't think it's a subtle

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: I'm proposing the following changes to the threading docs. Most of them are cleanups and small improvements, but I also rewrote the offending paragraph, and made the wait_for example more proeminent. -- Added file:

[issue8799] Hang in lib/test/test_threading.py

Charles-François Natali neolo...@free.fr added the comment: I'm proposing the following changes to the threading docs. Most of them are cleanups and small improvements, but I also rewrote the offending paragraph, and made the wait_for example more proeminent. Looks good to me. --

[issue8799] Hang in lib/test/test_threading.py

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 2f51dca92883 by Antoine Pitrou in branch '3.2': Issue #8799: Fix and improve the threading.Condition documentation. http://hg.python.org/cpython/rev/2f51dca92883 -- nosy: +python-dev

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: Ok, I've fixed the docs in 3.2 and 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson krist...@ccpgames.com added the comment: Here is a new patch. 1) I´ve simplified and relaxed test_notify() for Condition objects. Condition variables don't guarantee that there won't be any spurious wakeups so the test must maintain internal bookkeeping so that it

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: Condition variables don't guarantee that there won't be any spurious wakeups What do you mean? The implementation doesn't seem prone to spurious wakeups, and the docs don't say so either. I've added two generic tests of Condition objects in

[issue8799] Hang in lib/test/test_threading.py

Changes by Zsolt Cserna zsolt.cse...@morganstanley.com: -- nosy: +csernazs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799 ___ ___

[issue8799] Hang in lib/test/test_threading.py

New submission from Kristján Valur Jónsson krist...@ccpgames.com: The tests for the ConditionVariable a fragile. On a slow computer, or when running a DEBUG build, the main thread can issue a condition.notify() call, even though the worker threads have not settled in on a wait() call. This

[issue8799] Hang in lib/test/test_threading.py

Antoine Pitrou pit...@free.fr added the comment: Strange, I have never noticed this (even on the buildbots). -- nosy: +jyasskin, pitrou versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8799

[issue8799] Hang in lib/test/test_threading.py

Kristján Valur Jónsson krist...@ccpgames.com added the comment: Well, I saw this occasionally on my dual core laptop when working on the RWLock. A notify() before a target does a wait() is ineffective and it would wait indefinitely after the notify(5) call. This isn't a proper fix (I had