[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

STINNER Victor added the comment: Nick Coghlan added the comment: > +1 - after the further discussion, addressing this downstream as a patch > specifically to the pthread backend sounds good to me. Cool, I like when we agree :-) @Flavio Grossi: Sorry for you, but it's time to upgrade to

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Nick Coghlan added the comment: +1 - after the further discussion, addressing this downstream as a patch specifically to the pthread backend sounds good to me. -- ___ Python tracker

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

STINNER Victor added the comment: About the new optional balanced parameter added downstream to Fedora, the patch is very small compared to timedlock.patch. It only changes the Python code, not the C code: --- /home/haypo/prog/python/2.7/Lib/threading.py2014-11-05 15:05:11.432003853

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Flavio Grossi added the comment: > About the new optional balanced parameter added downstream to Fedora, the > patch is very small compared to timedlock.patch. It only changes the Python > code, not the C code The balancing fix has 3 main problems imo: - It causes long delays to receive the

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

STINNER Victor added the comment: "The balancing fix has 3 main problems imo:" Oh by the way, I don't want to apply it to Python 2.7 upstream for a similar reason: it's a new feature which would be added to a Python 2.7 minor version. We try to avoid that, even if Python 2.7 is special.

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Antoine Pitrou added the comment: Ok, let's close it then. -- resolution: -> wont fix status: open -> closed ___ Python tracker ___

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Nick Coghlan added the comment: The consistency issue I was referring to related to the "timeout" argument - we currently have a patch applied to Fedora (and derivatives) that instead adds a "balanced=True" flag argument so you can pass "polling=False" to turn off the busy loop (at the risk

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Antoine Pitrou added the comment: Yes. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

STINNER Victor added the comment: Nick, Antoine: do you agree to close this issue as WONTFIX for the reasons explained in msg250712? -- ___ Python tracker

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Flavio Grossi added the comment: First of all, thank you for your support. I fully understand what you are saying, however, being stuck to python 2.7 because of libraries still not ported to 3, this is a serious problem to us, and, while i agree this would introduce a new "feature", it also

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Changes by matteo : -- nosy: +matteo ___ Python tracker ___ ___ Python-bugs-list

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

STINNER Victor added the comment: 2015-09-15 9:17 GMT+02:00 Flavio Grossi : > however, being stuck to python 2.7 because of libraries still not ported to > 3, this is a serious problem to us, Are there private libraries or public libraries? If there are public, what are

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Flavio Grossi added the comment: >> however, being stuck to python 2.7 because of libraries > Are there private libraries or public libraries? It is a mix of public and internal libraries with the main public blockers being twisted and apache thrift (and other libs which have py3 alternatives

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Nick Coghlan added the comment: For the sake of folks writing single-source code, and needing to support Python 2.7 for at least as long as we're supporting it upstream, I believe it would be beneficial to have consistency here. For those that didn't follow the Fedora/RHEL issue chain, the

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

Antoine Pitrou added the comment: There's no consistency issue here, Python 3 just shows better performance and resource usage. Python 2 has always had the busy polling implementation. -- ___ Python tracker

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

STINNER Victor added the comment: As you noticed, this issue was correctly fixed in Python 3 by using the C timed acquire methods of locks, instead of polling. The problem is that Python 2 supports a wide range of threading models: Python/thread_atheos.h Python/thread_beos.h

[issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x)

New submission from Flavio Grossi: threading.Condition.wait(timeout=x) is implemented in python 2 as a semi-busy loop which causes cpu wakeups and unexpected cpu use. I think this is somewhat problematic since it causes problems in all modules which use that method, such as Queue.get() when