[issue15139] Speed up threading.Condition wakeup

Changes by Antoine Pitrou : -- nosy: +tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: In our 2.7 branches, this approach has been superseded with a natively impolemented _Condition class. This is even more efficient. It is available if the underlying Lock implementation is based on pthread locks (not semaphores). --

[issue15139] Speed up threading.Condition wakeup

Changes by Catalin Patulea : -- nosy: +Catalin.Patulea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue15139] Speed up threading.Condition wakeup

Gregory P. Smith added the comment: Nope. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue15139] Speed up threading.Condition wakeup

Matt Joiner added the comment: Did this make it into 3.3? -- nosy: +anacrolix ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: Thank you Richard. A new patch is included. Now the processing of "timeout" is done in _acquire_condition(). None is infinite, and negative timeouts are clipped to zero. Do you feel that it is unnecessary to be able to support other locks than Lock

[issue15139] Speed up threading.Condition wakeup

Richard Oudkerk added the comment: Currently negative timeouts are treated as zero timeouts by Condition.wait(). The patches turns them into errors. -- ___ Python tracker ___

[issue15139] Speed up threading.Condition wakeup

Changes by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: Well, the rationale for keeping the try_finally is that the Condition should continue to work with other Locks, as long as they provide _release_save and _acquire_restore methods. Lock._acquire_condtion onnly knows Lock and RLock intimately enough to

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: Made lock_acquire_condition() more robust, always acquiring the outer lock if possible. For Lock objects (not RLocks), set the "locked" variable that was recently added. -- Added file: http://bugs.python.org/file26117/condition.patch

[issue15139] Speed up threading.Condition wakeup

Martin v. Löwis added the comment: If the claim is that the _acquire_restore call becomes unnecessary, the entire try-finally should go. If that causes _acquire_restore to become unused, it should also go. -- ___ Python tracker

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: I'll fix the patch so that the lock is _always_ re-aqcuired. -- ___ Python tracker ___ ___

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: _acquire_condition() should _always_ re-aquire the outer lock, even for a timeout or an interrupt. I see however that it doesn't do so if there is an argument error, but that should not be a problem for an internal method, since it would mean that th

[issue15139] Speed up threading.Condition wakeup

Martin v. Löwis added the comment: I believe the patch is incorrect. It changes self._acquire_restore into a no-op, claiming that lock_acquire_condition will correctly restore the lock's state. However, lock_acquire_condition may fail (e.g. if the timeout is not strictly positive), in which

[issue15139] Speed up threading.Condition wakeup

Georg Brandl added the comment: Antoine is much more of an expert here, and I defer to his judgment that it is better to wait. -- ___ Python tracker ___ ___

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: hm, still one more day. It will be a pity to wait two more years, perhaps Georg is feeling lucky :) -- nosy: +georg.brandl ___ Python tracker ___

[issue15139] Speed up threading.Condition wakeup

Antoine Pitrou added the comment: > aw, that's too bad. Since this is not a feature implementat, we have > the entire beta cycle to shake out any possible bugs. We treat performance improvements as new features, though. -- ___ Python tracker

[issue15139] Speed up threading.Condition wakeup

Kristján Valur Jónsson added the comment: aw, that's too bad. Since this is not a feature implementat, we have the entire beta cycle to shake out any possible bugs. -- ___ Python tracker

[issue15139] Speed up threading.Condition wakeup

Antoine Pitrou added the comment: I think this should wait for 3.4. It's a bit too late now. -- nosy: +pitrou, sbt stage: -> patch review versions: +Python 3.4 -Python 3.3 ___ Python tracker _

[issue15139] Speed up threading.Condition wakeup

Changes by Jesús Cea Avión : -- nosy: +jcea ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue15139] Speed up threading.Condition wakeup

Changes by Kristján Valur Jónsson : Added file: http://bugs.python.org/file26086/queuetest.py ___ Python tracker ___ ___ Python-bugs-list mail

[issue15139] Speed up threading.Condition wakeup

New submission from Kristján Valur Jónsson : This patch is based on work previously done locally in python 2.7, see http://blog.ccpgames.com/kristjan/2012/05/25/optimizing-python-condition-variables-with-telemetry/ The idea is to acquire the signaling Lock() of the threading.Condition object _