New issue
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
Python doesn't support real time signals #56269
Comments
If a real time signal is raised 2 times whereas the signal is blocked, unblock the signal will call the signal handler twice. The C signal handler of the Python signal module only stores a boolean to say if the Python signal handler should be called or not in Py_CheckSignals(). If the C signal handler is called twice, the Python signal handler is only called once. Attached patch is a draft to fix this issue. The patch is not completly safe. |
example.py: example to demonstrate the problem. The Python signal handler is only called once, it should be called twice. |
Dunno.
Yeah it will not work without atomic ops. The NSIG detection of Modules/signalmodule.c uses 64 as a fallback. Often there is a huge whole in between NSIG and RTMIN, but And does anyone actually know why the last time i looked after this |
Is it a theoretical concern or does it affect real software? |
It's more theoretical. |
... Or we can maybe block the signals (all signals or just one signal?) using pthread_sigmask(SIG_BLOCK) while we access the Handlers array. But pthread_sigmask() is not available on all OSes. On my Linux box, Python 3.3 says that signal.NSIG is equal to 65 which looks correct.
The manpage says "The default action for an unhandled real-time signal is to terminate the receiving process." It is an arbitrary choice. Why do you care about the default action?
I don't understand: I don't use RTMAX in my patch. |
On FreeBSD NSIG only counts "old" signals (32, one 32 bit mask),
so that this seems to be somewhat constant in time.
So many syscalls for things which don't matter almost ever.
+ for (signum = 1; signum < NSIG; signum++) { This will not catch the extended signal range on FreeBSD. |
It's not the only shortage with the current implementation regarding (real-time) signals. Another one is that they're delivered out-of-order (lowest-numbered signal first), and the most important one - especially for real-time signals - is that the handlers are executed synchronously, when Py_CheckSignals() is called.
advantages:
drawbacks:
But I'm really not sure that fixing this is worth it... By the way, to be pedantic, in the current code, wakeup_fd and Handlers should be volatile, and tripped should be sig_atomic_t. |
Oh yes, it can be a problem.
Evaluate Python code in a signal handler is really not a good idea! And
Consume 2 FDs can be surprising. We cannot do that by default (just to
Oh yes, it can be a problem.
Do you really think that Windows supports real time signals? :) Windows
It looks like your reimplements the whole signal machinery between the Well, we can imagine to have an option/function to enable real time Can we call this mode "real time"? Real time means that we warranty a
Yes. Can you please write a patch for this? |
I know, you're limited to async-safe functions, among other things :-)
Nice.
Well, I think that we should either make this the default behaviour
Patch attached. |
if you used the pipe approach you'd need to deal with the case of the write blocking (or failing if nonblocking) when the pipe buffer is full. also you'd need to block signals around a fork and reinitialize the pipe in the child before reenabling signals. i think all of this is overkill. as said, this isn't a real problem. |
Well, a pipe is 64K on Linux (4K on older kernels). Given that each signal received consumes one byte, I'd be pretty surprised if we managed to fill the pipe before Py_CheckSignals() gets called.
Definitely. Do you think this can be closed as "wont fix" ? |
if someone comes up with a situation where this is a real problem, feel free to reopen it. |
New changeset 945ca78c38b1 by Victor Stinner in branch '3.1': New changeset b74999f561ca by Victor Stinner in branch '3.2': New changeset 1aa48391da30 by Victor Stinner in branch 'default': |
Ok I agree, no problem. But I commited at least Charles's patch ;-) |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: