gh-129401: Test repr rlock failing randomly

[YvesDup]

Fix and simplify a test of test_repr_rlock about multiprocessing.RLock primitive.
I am wondering if this fix must not be apply to the identical test of primitive multiprocessing.Lock (in test_repr_lock).

• see also test_multiprocessing_forkserver.test_processes.WithProcessesTestLock.test_repr_rlock is flaky #128206

• Issue: test_repr_rlock failing randomly on main branch CI #129401

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @colesbury for commit a801408 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F129959%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again.

[colesbury]

LGTM

[ruiyangke]

Hi @colesbury , I think we may need to backport this fix to 3.13, see #144381 (comment)

Also, we should add a p.join() after p.terminate(). see

cpython/Lib/test/_test_multiprocessing.py

Lines 1538 to 1545 in a447828

	p = self.Process(target=self._acquire_event,
	args=(lock, event),
	name='P2')
	p.start()
	event.wait()
	self.assertEqual(f'<Lock(owner=SomeOtherProcess)>', repr(lock))
	p.terminate()

What do you think? If that’s the right approach, I’d be happy to submit a PR.

[miss-islington-app]

Thanks @YvesDup for the PR, and @colesbury for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

[bedevere-app]

GH-144405 is a backport of this pull request to the 3.13 branch.

[colesbury]

Also, we should add a p.join() after p.terminate(). What do you think? If that’s the right approach, I’d be happy to submit a PR.

Yeah, that sounds right to me. Please open a PR