| msg155174 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2012-03-08 20:21 |
| Compare: $ ./python -c "import subprocess, signal, time; p = subprocess.Popen(['cat']); time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())" -2 with: $ ./python -c "import subprocess, signal, time; p = subprocess.Popen(['python', '-c', 'input()']); time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())" Traceback (most recent call last): File "", line 1, in KeyboardInterrupt 1 Python's behaviour apparently breaks a common assumption towards Unix processes (see bug reported at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652926). A solution would be to add a signal number attribute to KeyboardInterrupt, and use that value when computing the process exit code. |
|
|
| msg155209 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2012-03-09 07:14 |
| I'm not so sure that Python is in violation of the convention here. The exit code should report *unhandled* signals, indicating that the process didn't provide an exit code at all (as it didn't call exit(2)). You are supposed to use WIFEXITED/WIFSIGNALED/WIFSTOPPED on the status code, and interpret it as an exit code only if WIFEXITED. Since Python *does* handle the signal, and exits "regularly", we shouldn't (and probably even can't) claim that we didn't exit (unless we raise the signal again instead of exiting). |
|
|
| msg155244 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-03-09 16:38 |
| Another problem with my suggestion is that C exit() ANDs the status with 255 before transmitting it to the parent. |
|
|
| msg155245 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-03-09 16:40 |
| (faulthandler works around that problem by restoring the previous signal handler and calling raise(), apparently) |
|
|
| msg155353 - (view) |
Author: Éric Araujo (eric.araujo) * |
Date: 2012-03-10 21:39 |
| The Debian bug has some more convincing examples: > any Python program which is expected to implement the interface of (say) "diff" is buggy, because > it may exit status 1 ("comparison successful; differences found") when it should have died with > SIGINT ("comparison not completed due to interrupt signal"); this could in principle cause data loss > in some applications. |
|
|
| msg155354 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-03-10 21:44 |
| > Since Python *does* handle the signal, and exits "regularly", we > shouldn't You are arguing from a legal point of view, but from a pratical point of view Python doesn't really "handle" the signal: it just defers the exit until after all internal structures are cleaned up. |
|
|
| msg156446 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2012-03-20 18:56 |
| I agree with Martin: we really do handle the signal, and as such, the only way to convey the relevant information to the parent as to which signal caused the exit would be to re-raise it, which is really ugly and probably not a good idea. Processes that want default behavior upon signal reception (so that they can use WEXITSTATUS(), WCOREDUMP() and friends) can always use SIG_DFL: $ python -c "import subprocess, signal, time; p = subprocess.Popen(['python', '-c', 'import signal; signal.signal(signal.SIGINT, signal.SIG_DFL); input()']); time.sleep(1); p.send_signal(signal.SIGINT); print(p.wait())" -2 |
|
|
| msg156447 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-03-20 19:05 |
| > I agree with Martin: we really do handle the signal, and as such, the > only way to convey the relevant information to the parent as to which > signal caused the exit would be to re-raise it, which is really ugly > and probably not a good idea. Why would it be ugly? faulthandler does exactly that. |
|
|
| msg156458 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2012-03-20 20:34 |
| >> I agree with Martin: we really do handle the signal, and as such, the >> only way to convey the relevant information to the parent as to which >> signal caused the exit would be to re-raise it, which is really ugly >> and probably not a good idea. > > Why would it be ugly? faulthandler does exactly that. Because calling exit() is the right way to end a process. For example, it does the following: - atexit()-registered finalizers are run - stdio streams are flushed and closed (although it could probably done by the interpreter) - files created with tmpfile() are removed (on POSIX systems, they're removed after creation, but you can imagine an implementation where they would need to be explicitely removed upon close) This would not be performed if the signal is raised. Since the user has the possibility of restoring default signal handlers with SIG_DFL, I think we could stcik with the current behavior. |
|
|
| msg157304 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2012-04-01 15:39 |
| > Because calling exit() is the right way to end a process. For example, > it does the following: > - atexit()-registered finalizers are run > - stdio streams are flushed and closed (although it could probably > done by the interpreter) > - files created with tmpfile() are removed (on POSIX systems, they're > removed after creation, but you can imagine an implementation where > they would need to be explicitely removed upon close) > > This would not be performed if the signal is raised. > Since the user has the possibility of restoring default signal > handlers with SIG_DFL, I think we could stcik with the current > behavior. Ah, ok, I agree with you, then. |
|
|