Make `cell` thread-safe in the free-threaded build

[colesbury]

Feature or enhancement

From the docs: “Cell” objects are used to implement variables referenced by multiple scopes.

Currently, modifying cell contents concurrently with other accesses is not thread-safe without the GIL. This shows up, for example, in test_signal.test_stress_modifying_handlers, which modifies the num_received_signals variable from multiple threads:

cpython/Lib/test/test_signal.py

Lines 1352 to 1374 in 9a388b9

	def test_stress_modifying_handlers(self):
	# bpo-43406: race condition between trip_signal() and signal.signal
	signum = signal.SIGUSR1
	num_sent_signals = 0
	num_received_signals = 0
	do_stop = False
	def custom_handler(signum, frame):
	nonlocal num_received_signals
	num_received_signals += 1
	def set_interrupts():
	nonlocal num_sent_signals
	while not do_stop:
	signal.raise_signal(signum)
	num_sent_signals += 1
	def cycle_handlers():
	while num_sent_signals < 100 or num_received_signals < 1:
	for i in range(20000):
	# Cycle between a Python-defined and a non-Python handler
	for handler in [custom_handler, signal.SIG_IGN]:
	signal.signal(signum, handler)

Linked PRs

• gh-117323: Make cell thread-safe in free-threaded builds #117330

[colesbury]

It would be nice to have a faster thread-safety strategy for cell, but we can address that later.