Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
subprocess: restore backwards-compatibility with python2 #1063
In python2, restore_signals doesn't exist, and the default behavior is
This change sets the correct default option for py2, and leaves the
Thanks for this PR. Fidelity to the standard library is an important concern of gevent.
The zen says "practicality beats purity", and here that can cut both ways.
The argument for the current behaviour is that having the (few) signals that Python ignores by default be restored for exec'd children is generally a more sane behaviour, which is why it was made the default in Python 3. I don't see the Python 2 behaviour documented, nor do I find any Python 2 tests in the standard library broken by changing it, so I would tend to consider it to be "implementation defined" behaviour, and as such I would prefer not to have the sanity removed by default under Python 2 again.
Can you talk a little bit about what problems you experienced as a result of this to provide context for the other side?
I would support allowing
I checked out cpython source to figure out that the default behavior was to not restore the signals.
The bug occured because we run a python process as a systemd service; systemd masks sigpipe for all its services by default. (The reasoning being that except for shells, sigpipe is useless and just a chore. It does provide a way to not mask sigpipe.) Only when running a subprocess were we getting sigpipe instead of EPIPE, which was killing the subprocess, which was very odd because of systemd's behavior that we expected.
We have solved this by fixing the sigpipe to begin with, but gevent's behavior was surprising given that default behavior of py2's stdlib.
So, in and of itself, we don't need this PR to be merged, it just fixes what we thought was an accidental bug.
Sure, but what about PyPy or Jython or IronPython or micropy? These are all implementations of Python, and the CPython implementation behaviour does not define the Python specification. gevent does run on at least one of those other implementations.
Thanks for the explanation! So when you upgrade your process to run under Python 3, you'll have to take the additional step of adding
OK, cool. I'll leave this open as a reminder to improve the documentation and/or enable the