RE: Handle SIGINT in Python

[<Paul_Koning@Dell.com>]

I think the way to make this work is that a C-c in Python is a "KeyboardInterrupt" Python exception.  That can be caught in Python but rarely is.  If not, it would unwind to the interpreter.  A normal Python interpreter would print the default traceback for that exception, exactly as it does for any other exception, it doesn't give interrupt special treatment.  

To get what you're asking (C-c work like in non-Python settings in GDB) all that would be needed is for the interpreter top level to check for specifically the KeyboardInterrupt exception and give that to the GDB C-c handler, rather than printing the default exception traceback.  It would still do that for other (non-interrupt) exceptions.

	paul

-----Original Message-----
From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Tom Tromey
Sent: Wednesday, January 11, 2012 3:56 PM
To: Doug Evans
Cc: Khoo Yit Phang; gdb-patches@sourceware.org
Subject: Re: Handle SIGINT in Python

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> There is value in having the SIGINT *only* affect the inferior.
Doug> It's up to the script to handle the various reasons why the 
Doug> inferior may have stopped, and you don't (generally) want to 
Doug> interfere with that (by interrupting the script too).

I think Python code should have to request something like this specially.  The scripting case is less usual than the interactive debugging (perhaps with some Python helper code) case.  I think it would be weird for the behavior the user sees, by default, to depend on whether Python or GDB code was active at the moment of C-c.

That is, a C-c when processing a 'python' command in a breakpoint's 'commands' list should have the same general effect as if we were processing any other command.

Tom