Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid using Py_AddPendingCall from signal handler, to avoid calling signal-unsafe functions.
|
To be frank I'm not sure if |
|
@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 |
|
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)
Based on PR #2415.