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 another thread).

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_atomic_t. Reading and writing this data type is guaranteed to happen in a single instruction, so there’s no way for a handler to run “in the middle” of an access."

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.

New changeset2c8a5e4c968217f9672340e520942c4ed788d8de 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

New changeset57e836cb41656ac23042886db6b5985c036a7ce2 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/57e836cb41656ac23042886db6b5985c036a7ce2