Re: Handle SIGINT in Python

[Khoo Yit Phang <khooyp@cs.umd.edu>]

Hi,

On Jan 20, 2012, at 4:33 PM, Tom Tromey wrote:

>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
> 
> Tom> Could we possibly solve this problem without constantly resetting the
> Tom> SIGINT handler?  Maybe via a combination of a global flag plus a call
> Tom> into Python from handle_sigint?
> 
> Yit> It is possible, I just need a way to call PySet_Interrupt. But it
> Yit> seems to be that it would require adding hooks to events-top.c and,
> Yit> which seems like a separate project.
> 
> I think of it more as a different implementation of the feature...

In the long run, I do think that changing events-top.c is better, but I've to figure out how it should look like, for Python and other clients.

> Tom> Our python->gdb exception story is not super.  And, we lose information
> Tom> in the round trip.  This might (or might not...) be a prerequisite to
> Tom> solving this problem.
> 
> Yit> I don't think it's a problem, unless for nested calls to python like
> Yit> "py gdb.execute('py ...')".
> 
> You can't fully predict what gdb actions will cause Python code to run.

Actually, I don't think I understand what you mean. Can you give an example? (Is it related to scenario 1 below?)

> Also, Python frequently calls into gdb.  Any place in gdb that invokes
> QUIT could potentially see a C-c.  However, IIUC, with your patch these
> QUITs will be inactive if there is Python code up the stack -- but this
> means that some slow things in gdb will be uninterruptible.

I think there are two scenarios here:

1. When the call stack is GDB -> Python, Ctrl-C will only interrupt the Python part (unless there's special handling in the GDB part to treat KeyboardInterrupt). You would have to press Ctrl-C again to interrupt the GDB part immediately after. I wondered whether to have Ctrl-C interrupt the entire stack; it's fairly easy to do, since every Python entry is wrapped by ensure_python_env (just check for KeyboardInterrupt during cleanup and raise QUIT).

Though, there was some debate earlier in the mailing list on something related: whether Ctrl-C during gdb.execute should interrupt Python too. The concern was that there may be legitimate reasons to interrupt only part of the call stack, and the decision should depend on the particulars of the task.

2. When the call stack is GDB -> Only gdb.execute is interruptible now, since that's the only place I've suspended Python's interrupt handler. There may be other Python methods that call into GDB that is slow that could use the same treatment.

Yit
January 22, 2012