Re: Handle SIGINT in Python

[Kevin Pouget <kevin.pouget@gmail.com>]

On Thu, Jan 12, 2012 at 5:47 PM,  <Paul_Koning@dell.com> wrote:
>>just my 2 cents to the discussion.
>>[I'm not sure I could follow all the arguments, so my comments are based on Khoo's patch]
>>
>>+static void
>>+gdbpy_handle_sigint (int sig)
>>+{
>>+  PyErr_SetInterrupt ();
>>+}
>>

>
> The only difference is in what happens when you get to the top of a Python script with a KeyboardInterrupt exception and no one is catching it.  In an interactive session (python shell) you get a backtrace.  I think in a Python interactive session inside GDB ("python" command with no arguments) the same should be true.  In a script invocation from the command shell (outside GDB) you'd also get a traceback in this case.  In GDB, you probably should not, as was discussed earlier; in that case, the interrupt should be passed up to the GDB common machinery to handle exactly as it would handle an interrupt for any other command, without a Python style traceback printout.

On Thu, Jan 12, 2012 at 4:35 PM, Khoo Yit Phang <khooyp@cs.umd.edu> wrote:
> Your concern does not arise: PyErr_SetInterrupt does not raise any exception, it simply sets a flag which Python checks every now and then in the
> interpreter loop. The same thing happens for any Python exception that is raised in C: you would set an exception via PyErr_SetString(exception,
> message) or similar, and return NULL or -1 to the interpreter.


Thanks for the clarifications, but I'm still not unsure about how to
build a reliable application on top of GDB with this kind of SIGINT
handling.
I'm not an expert on Python programming nor on 'reliable application
design' (and I'm used to C programming) so please bear with me if
there are some flaws in my arguments, I'm just trying to figure out
how this patch would influence my code:)


> Any Python statement can throw a KeyboardException.
That could make sense in a stateless / lightweight application, but in
[my] GDB-base Python application, I can't see how this can remain the
default behavior ... I'm a bit stuck with the FLAG handling I
described in the previous mail, 1 C^c sets a flag, 2 C^c raises an
exception (and almost kills the app), but I can't see any other way to
safely handle this SIGINT.

(or I can implement the flag mechanism by myself, as in
http://stackoverflow.com/a/4205386/341106:
> import signal
> def signal_handler(signal, frame):
>    print 'You pressed Ctrl+C!'
>    # what ever ...
> signal.signal(signal.SIGINT, signal_handler)

but I guess I would still have to surround GDB function calls with
KeyboardInterrupt handling ...)


Cordially,

Kevin