-
-
Notifications
You must be signed in to change notification settings - Fork 32.7k
Description
Bug report
Bug description:
The implementation of test_multiprocessing_forkserver.test_processes.WithProcessesTestLock.test_repr_rlock
is racy; this leads to test failures on unrelated PRs:
The linked failures are a result of the raciness in the test:
cpython/Lib/test/_test_multiprocessing.py
Lines 1525 to 1530 in 30efede
t = threading.Thread(target=self._acquire_release, | |
args=(lock, 0.2), | |
name=f'T1') | |
t.start() | |
time.sleep(0.1) | |
self.assertEqual('<RLock(SomeOtherThread, nonzero)>', repr(lock)) |
and the function, _acquire_release
, which runs in the thread:
cpython/Lib/test/_test_multiprocessing.py
Lines 1489 to 1497 in 30efede
@staticmethod | |
def _acquire_release(lock, timeout, l=None, n=1): | |
for _ in range(n): | |
lock.acquire() | |
if l is not None: | |
l.append(repr(lock)) | |
time.sleep(timeout) | |
for _ in range(n): | |
lock.release() |
The tests will fail if _acquire_release
runs to completion or doesn't acquire the lock before the test checks the repr.
We should rewrite test_repr_rlock
so that it does not use time.sleep()
as a mechanism for ordering events between different processes/threads.
CPython versions tested on:
CPython main branch
Operating systems tested on:
Linux