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

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.

[picnixz]

This conversation seems to go against our AI policy. Human interaction is necessary, don't let your agents in automated mode. Please read https://devguide.python.org/getting-started/ai-tools/#guidelines-for-using-ai-tools.

[bhuvi27]

This conversation seems to go against our AI policy. Human interaction is necessary, don't let your agents in automated mode. Please read https://devguide.python.org/getting-started/ai-tools/#guidelines-for-using-ai-tools.

Sorry — I used an AI assistant to draft PR replies and posted them
without reviewing properly (the first one was off-topic). I'll handle
discussion myself from here.

On the technical side: I understand the mutex doesn't protect reads
through sys.flags. I'm happy to rework the approach once there's
guidance on whether runtime updates to sys.flags should stop entirely.