bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state#2417
bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state#2417pitrou merged 6 commits intopython:masterfrom
Conversation
Avoid using Py_AddPendingCall from signal handler, to avoid calling signal-unsafe functions.
|
To be frank I'm not sure if |
pitrou
changed the title
|
@Haypo any concerns here? |
I disagree with the "trivial" label. You need to add a bpo number. I don't understand the rationale of using an atomic type, can you please elaborate? |
|
"Based on" just means it contains the changes from that PR. Now that it's merged, it doesn't matter anymore. |
There is no "trivial" label :-)
"Atomic" types are needed for proper interaction between concurrent running portions of code that don't use locks. Imagine trip_signal() in one thread and PyErr_CheckSignals() in another thread, for example. We already use them in |
pitrou
changed the title
|
Ah, thanks for the link to http://bugs.python.org/issue30808 |
|
@cf-natali, I'd like your advice here. |
|
I'm thinking a lock would be better here, atomics are great for a single flag variable or ref count. In this case there's an array of flags and another thread might change tripped before it's set to 0 and losing a signal or several? I haven't dug into how this code is called so it may be a non-issue. |
|
Unfortunately, locks can't be used in signal-handling code. |
|
ahh right. Then this is a clear improvement over the current situation, 👍 |
…state (pythonGH-2417) * Improve signal delivery Avoid using Py_AddPendingCall from signal handler, to avoid calling signal-unsafe functions. * Remove unused function * Improve comments * Use _Py_atomic API for concurrency-sensitive signal state * Add blurb (cherry picked from commit 2c8a5e4)
4 participants
Based on PR #2415.