Make `_warnings.c` thread-safe in free-threaded build

[colesbury]

Feature or enhancement

The warnings implementation is split between Python (warnings.py) and C (_warnings.c). There are a few bits of code in the C module that are not thread-safe without the GIL:

The Py_SETREF calls are not thread-safe if concurrent writers try to overwrite the same field (e.g., st->once_registry). We can probably use critical sections to make it thread-safe.

get_once_registry:

cpython/Python/_warnings.c

Line 259 in df4784b

Py_SETREF(st->once_registry, registry);

get_default_action:

cpython/Python/_warnings.c

Line 290 in df4784b

Py_SETREF(st->default_action, default_action);

get_filter:

cpython/Python/_warnings.c

Line 315 in df4784b

Py_SETREF(st->filters, warnings_filters);

Some uses of borrowed references are likely not thread-safe

• _PyDict_GetItemWithError (replace with PyDict_GetItemRef?)

Linked PRs

• gh-116664: Ensure thread-safe dict access in _warnings #116768
• gh-116664: Make module state Py_SETREF's in _warnings thread-safe #116959
• gh-116664: Fix unused var warnings in _warnings.c in non-free-threaded builds #117373
• gh-116664: In _warnings.c, make filters_version access thread-safe #117374

[erlend-aasland]

I'd like to take a stab at this.

[erlend-aasland]

FYI: My CPython time is very fragmented these days, so I'll move forward with a handful of smaller PRs instead of one PR that fixes everything.

[erlend-aasland]

For the module state setref operations: AFAICS all of these happen in warn_explicit()¹ helpers, so perhaps we can get away with running the warn_explicit() calls as critical sections.

Footnotes

1. the C function, not the Python API ↩