Author gregory.p.smith
Recipients SamB, foom, gregory.p.smith, jwilk, loewis, martin.panter, mwh, petri.lehtinen, pitrou, rnk, vstinner
Date 2019-02-13.23:58:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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 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 check if the + 128 trick were deemed too magical despite being what everyone likely implements, standardized or not)
Date User Action Args
2019-02-13 23:58:34gregory.p.smithsetrecipients: + gregory.p.smith, mwh, loewis, foom, pitrou, vstinner, jwilk, rnk, petri.lehtinen, martin.panter, SamB
2019-02-13 23:58:34gregory.p.smithsetmessageid: <>
2019-02-13 23:58:34gregory.p.smithlinkissue1054041 messages
2019-02-13 23:58:34gregory.p.smithcreate