gh-151218: Fix data race in sys_set_flag for free-threading

[bhuvi27]

Fixes #151218

Concurrent calls to sys.set_int_max_str_digits() in free-threaded builds
could double-free the same sys.flags tuple item because sys_set_flag()
updated the slot without synchronization.

Protect sys.flags updates with a mutex in free-threaded builds, and hold
the same lock across flag and interpreter int_max_str_digits state updates
so sys.get_int_max_str_digits() stays consistent with sys.flags. Add a
concurrent stress regression test in test_sys.py.

• Issue: Data race in sys_set_flag when sys.set_int_max_str_digits() is called concurrently with free-threaded build #151218

[picnixz]

Please do not force push. To contribute cleanly, please read https://devguide.python.org/getting-started/pull-request-lifecycle/#pullrequest.

[da-woods]

This doesn't guard the read though. And the read through sys.flags is probably difficult to guard because it's an "immutable" object and so shouldn't be changing once it's visible

[bhuvi27]

This doesn't guard the read though. And the read through sys.flags is probably difficult to guard because it's an "immutable" object and so shouldn't be changing once it's visible

Thanks for the pointer — I force-pushed while fixing CI and cleaning up commits. I’ll use additive commits from here on and have read the PR lifecycle guide.

[bhuvi27]

This doesn't guard the read though. And the read through sys.flags is probably difficult to guard because it's an "immutable" object and so shouldn't be changing once it's visible

Good point — you're right that the read path through sys.flags isn't
guarded by the new mutex, so a reader can still observe the old slot
while a writer replaces and decref's it (use-after-free).

A few options I see:

1. Stop updating sys.flags.int_max_str_digits at runtime entirely —
   treat sys.flags as startup-only (its documented immutability),
   and let sys.get_int_max_str_digits() be the single source of truth
   for the current value. This removes the racy shared object.

2. Atomic store/load of the slot pointer plus deferred reclamation
   (QSBR) for the old value — keeps the current API but is more
   machinery.

3. Replace sys.flags with a fresh struct sequence on each update.

Option 1 looks cleanest and matches the "immutable" intent, but it's
a behaviour change. Which direction would you prefer? Happy to redo
the PR around option 1 if that's the right call.