[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

Antoine Pitrou added the comment: New changeset 57e836cb41656ac23042886db6b5985c036a7ce2 by Antoine Pitrou in branch '3.6': [3.6] bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (GH-2417) (#3007) https://github.com/python/cpython/commit/57e836cb41656ac23042886db6b5985c036a

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

Changes by Antoine Pitrou : -- pull_requests: +3041 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

Antoine Pitrou added the comment: New changeset 2c8a5e4c968217f9672340e520942c4ed788d8de by Antoine Pitrou in branch 'master': bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (#2417) https://github.com/python/cpython/commit/2c8a5e4c968217f9672340e520942c4ed788d8de ---

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

Changes by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

Antoine Pitrou added the comment: Look at the PR :-) That's what we used. But, while sig_atomic_t guarantees that accesses are atomic, it doesn't enforce a memory order. So the CPU (depending on the architecture) is free to reorder writes. -- ___

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

STINNER Victor added the comment: There is a sig_atomic_t type. Should we use that one? https://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html "To avoid uncertainty about interrupting access to a variable, you can use a particular data type for which access is always atomic: sig_a

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

Changes by Antoine Pitrou : -- pull_requests: +2553 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mai

[issue30808] Use _Py_atomic API for concurrency-sensitive signal state

New submission from Antoine Pitrou: We already use the _Py_atomic APIs in ceval.c, for lockless boolean flags. We should do the same in the signal module where there are similar concurrency issues (for example between the signal handler running in one thread and PyErr_CheckSignals running in