You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make _warnings.c thread-safe in free-threaded build #116664
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.
For the module state setref operations: AFAICS all of these happen in warn_explicit()1 helpers, so perhaps we can get away with running the warn_explicit() calls as critical sections.
_warnings._filters_mutated: Yes, I think so. Although I think the whole way it's used in catch_warnings is not really thread-safe even with the GIL.
👍 BTW, I'm a little bit sceptical about using the @critical_section Argument Clinic directive here, since that uses the module object, and not the mutex in the module state, to lock the critical section. Perhaps it does not matter.
already_warned(...): I think the calling code already does the locking? It would be good to add an assertion that it's locked at least.
Activity
erlend-aasland commentedon Mar 12, 2024
I'd like to take a stab at this.
erlend-aasland commentedon Mar 13, 2024
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.
gh-116664: Ensure thread-safe dict access in _warnings (#116768)
erlend-aasland commentedon Mar 18, 2024
For the module state setref operations: AFAICS all of these happen in
warn_explicit()1 helpers, so perhaps we can get away with running thewarn_explicit()calls as critical sections.Footnotes
the C function, not the Python API ↩
pythongh-116664: Make module state Py_SETREF's in _warnings thread-safe
pythongh-116664: Ensure thread-safe dict access in _warnings (python#…
pythongh-116664: Ensure thread-safe dict access in _warnings (python#…
gh-116664: Make module state Py_SETREF's in _warnings thread-safe (#1…
erlend-aasland commentedon Mar 29, 2024
BTW, don't we need to protect
_warnings._filters_mutated?cpython/Python/_warnings.c
Lines 1169 to 1182 in 0fa571d
Possibly also the
already_warned(...)calls, since that function readsst->filters_version.erlend-aasland commentedon Mar 29, 2024
(Reopening; #116959 introduced compilation warnings on non-free-treaded builds.)
colesbury commentedon Mar 29, 2024
_warnings._filters_mutated: Yes, I think so. Although I think the whole way it's used incatch_warningsis not really thread-safe even with the GIL.already_warned(...): I think the calling code already does the locking? It would be good to add an assertion that it's locked at least.pythongh-116664: Fix unused var warnings in _warnings.c in non-free-t…
erlend-aasland commentedon Mar 29, 2024
👍 BTW, I'm a little bit sceptical about using the
@critical_sectionArgument Clinic directive here, since that uses the module object, and not the mutex in the module state, to lock the critical section. Perhaps it does not matter.Yep, an assert would be good.
gh-116664: Fix unused var warnings in _warnings.c in non-free-threade…
gh-116664: In _warnings.c, make filters_version access thread-safe (#…
Squashed commit of the following:
Squashed commit of the following:
pythongh-116664: Ensure thread-safe dict access in _warnings (python#…
pythongh-116664: Make module state Py_SETREF's in _warnings thread-sa…
pythongh-116664: Fix unused var warnings in _warnings.c in non-free-t…
pythongh-116664: In _warnings.c, make filters_version access thread-s…