Gregory P. Smith <g...@krypto.org> added the comment:
Taking a renewed look at this 8 years later... I agree, re-triggering the signal with the SIG_DFL handler would prevent us from doing the existing interpreter shutdown cleanup if we did it too early which would be a behavior change other than the exit value correction. So we should delay the re-signaling kill(getpid(), SIGINT) call until we've completed that and are about to exit anyways. The code has moved around a lot since i generated this patch on a 3.2-ish tree so it'll take me a while to untangle what would need to go where to create a PR. Instead of kill(getpid(), SIGINT) or raise(SIGINT), we could just checking the _UnhandledKeyboardInterrupt flag we return our exit valye adjusting it to be the one a calling shell may be expecting to indicate a SIGINT. That goes against the advice of https://www.cons.org/cracauer/sigint.html but is likely to work. A question that leads to is what _is_ the correct value. On Linux the magic 130 happens to be (SIGINT + 128). Triggering the libc or kernel supplied SIG_DFL handler as a final act avoids us ever needing to know what possible mechanisms to indicate this to the parent process are preferred on a platform. (if we know it is merely an exit value we could capture that in to a #define with a configure.ac check if the + 128 trick were deemed too magical despite being what everyone likely implements, standardized or not) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1054041> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
