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
Add Linux's signalfd() to the signal module #76624
Comments
We should add a wrapper for both signalfd() and a function to read and decode the structure from the fd into a dataclass. The code we need to build such a thing from appears to exist in BSD & MIT licensed form in: PyPI contains two extension module wrappers of just the system call: Why add this Linux specific API to the standard library? I believe I could use signalfd() within the subprocess module to get rid of the need to busy-loop-poll to see when children have exited on subprocess.Popen.wait() calls with a timeout. [a proof of concept using the above modules would be a good idea first] |
An example subprocess improvement using sigtimedwait() - #5035 - led me to believe that signalfd() is superior as it sounds like signalfd() does not require pthread_sigmask (sigprocmask) global state manipulation calls. I have not confirmed if that is true. |
See also https://bugs.python.org/issue12304 |
Also see how the forkserver module does without it: Reading Jean-Paul's messages in https://bugs.python.org/issue8407, I'm unclear what is required to take advantage of signalfd(). Jean-Paul says """In order to effectively use signalfd(), the signals in question must be blocked, though""". The signalfd man page says: """Normally, the set of signals to be received via the file descriptor should be blocked using sigprocmask(2), to prevent the signals being handled according to their default dispositions""". And it's not clear what is meant by that (what happens if you don't block those signals?). Also: """As a consequence of the read(2), the signals are consumed, so that they are no longer pending for the process (i.e., will not be caught by signal handlers, and cannot be accepted using sigwaitinfo(2)).""" But how about the converse? i.e. can a signal be consumed first by a signal handler and the fd not written to at all? Also see fork() semantics which might (or not) require special handling. Also see https://bugs.python.org/issue31489 for an issue related to fork(), signals and fds. |
My reading of the Linux signalfd man page may be optimistic. :) Regardless, it'd be nice to have it available in the stdlib so it could be used if deemed useful. I expect this to only ever be added by someone making use of it in another stdlib module. As for what multiprocessing.forkserver does, the old manual signal handler and pipe trick is a reasonably well known one. But a forkserver is not safe to be started when threads exist. (unlike subprocess) Signals are process global state, no thread compatible library can rightfully take ownership of a one. |
Agreed.
But then is the signalfd() idea for subprocess doomed as well? |
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: