[Python-Dev] Default SIGINT handling dangerous?

Jurko Gospodnetić jurko.gospodnetic at pke.hr
Sun Dec 15 00:09:21 CET 2013


On 14.12.2013. 17:14, R. David Murray wrote:
> On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti" <jurko.gospodnetic at pke.hr> wrote:
>>     My scripts replace the default SIGINT/SIGBREAK signal handlers as
>> soon as possible, and everything works great after that, but things get
>> ugly if Ctrl-C is pressed before the script gets a chance to do this. I
>> could even live with an 'exit with an ugly traceback', but having the
> process hang or fail so that Windows reports it as non-responding or
>> reports it as 'stopped working' and offers to send failure information
>> to Microsoft? That just leaves a bad taste in my mouth. :-(
> This sounds like a more troubling variation on the issue raised in
> issue 14288 (http://bugs.python.org/issue14228).  The solution proposed
> there would appear to be something that would help you, so you might
> want to chime in on that issue.

   Thanks for the tip. I've seen the bug report you mention before, but 
thought to first inquire about the issue on the mailing list. I'll chime 
in what I know to the bug report.

   Final solution proposed there is to add a command-line option to 
delay enabling current default Python SIGINT handling until after the 
site.py package has been loaded.

   That would most likely avoid the startup crashes I mentioned in the 
original post.

   On Unix it would make Ctrl-C silently terminate the process if it 
occurs before default Python signal handling is enabled. I do not know 
what effect this would have on Windows - possibly the signal would 
simply be ignored & lost.

   It would also still leave a slight window between when Python sets up 
its default SIGINT handling and when user code has a chance to set up 
its own.

   My first instinct is to not do that and instead add an option to 
block SIGINT handling and allow user code to enable its own or default 
Python handling as it wishes and then unblock SIGINT handling. Note that 
by 'blocking' a signal I do not mean losing/ignoring it but delaying its 
handling until signal handling is unblocked.

   Best regards,
     Jurko Gospodnetić

More information about the Python-Dev mailing list