Description of problem:
pthreading.Condition uses Lock by default, but threading.Condition uses RLock. This prevents usage of pthreading.Condition as a drop-in replacement for threading.Condition.
Version-Release number of selected component (if applicable):
The relevant code:
101 class Condition(object):
103 Condition class mimics Python native threading.Condition() API
104 on top of the POSIX thread conditional variable synchronization
107 def __init__(self, lock=None):
108 self.__lock = lock if lock else Lock()
254 class _Condition(_Verbose):
255 """Condition variables allow one or more threads to wait until they are
256 notified by another thread.
259 def __init__(self, lock=None, verbose=None):
261 if lock is None:
262 lock = RLock()
263 self.__lock = lock
Users of this class can assume that a Condition has a recursive lock, and they
will be surprised when their code will deadlock because pthreading changed the default.
It would require us to implement the internal interfaces required for that kind of thing to work.
You have to make condition.wait() to actually release the lock up to it's last reference and that do a wait() and when reacquire the lock get the ref count to where it's original count.
Since it hasn't caused an issue, ever, for a few versions now. I don't think it's 3.5. Please move to 3.6.
For vdsm, we could not care less about Python questionable default, and I prefer that we do not add code to pthreading.RLock that makes it work with conditions.
The best solution would be to break the compatibility with Python Condition (nobody needs that), and prevent creation of Condition without a lock, or with a RLock, because this usage is bad idea and for vdsm we should not allow it.
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
I think we should close this, as pthreading default is fine for vdsm, and we are
we want to kill pthreading anyway moving to python 3.