Use _Py_atomic API for concurrency-sensitive signal state

[pitrou]

BPO	30808
Nosy	@pitrou, @vstinner
PRs	bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state #2417 [3.6] bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (GH-2417) #3007

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2017-07-17.10:25:40.121>
created_at = <Date 2017-06-29.20:01:06.342>
labels = ['interpreter-core', 'type-feature', '3.7']
title = 'Use _Py_atomic API for concurrency-sensitive signal state'
updated_at = <Date 2017-08-06.17:32:41.763>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2017-08-06.17:32:41.763>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2017-07-17.10:25:40.121>
closer = 'pitrou'
components = ['Interpreter Core']
creation = <Date 2017-06-29.20:01:06.342>
creator = 'pitrou'
dependencies = []
files = []
hgrepos = []
issue_num = 30808
keywords = []
message_count = 5.0
messages = ['297304', '297313', '297315', '298478', '299806']
nosy_count = 4.0
nosy_names = ['pitrou', 'vstinner', 'jyasskin', 'neologix']
pr_nums = ['2417', '3007']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue30808'
versions = ['Python 3.7']

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

[vstinner]

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."

[pitrou]

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.

[pitrou]

New changeset 2c8a5e4 by Antoine Pitrou in branch 'master':
bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (bpo-2417)
2c8a5e4

[pitrou]

New changeset 57e836c by Antoine Pitrou in branch '3.6':
[3.6] bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (GH-2417) (bpo-3007)
57e836c