Bug 1117956

The relevant code:

101 class Condition(object):
102     """
103     Condition class mimics Python native threading.Condition() API
104     on top of the POSIX thread conditional variable synchronization
105     primitive.
106     """
107     def __init__(self, lock=None):
108         self.__lock = lock if lock else Lock()

Python code:

254 class _Condition(_Verbose):
255     """Condition variables allow one or more threads to wait until they are
256        notified by another thread.
257     """
258 
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.