This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients Arfrever, eric.araujo, loewis, nadeem.vawda, neologix, pitrou, rosslagerwall
Date 2012-03-20.20:34:53
SpamBayes Score 4.7285833e-09
Marked as misclassified No
Message-id <CAH_1eM04aYwuRr_gNMvM2U6uwvb4R+5yZQPMbL04xf-+rqFiEw@mail.gmail.com>
In-reply-to <1332270077.3440.7.camel@localhost.localdomain>
Content
>> 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.
History
Date User Action Args
2012-03-20 20:34:54neologixsetrecipients: + neologix, loewis, pitrou, nadeem.vawda, eric.araujo, Arfrever, rosslagerwall
2012-03-20 20:34:53neologixlinkissue14229 messages
2012-03-20 20:34:53neologixcreate