Re: [PATCH 2/4]: Handle SIGINT under Python by raising KeyboardInterrupt

[Khoo Yit Phang <khooyp at cs dot umd dot edu>]

Hi,

On Jul 25, 2012, at 5:06 PM, Tom Tromey wrote:

>>>>>> "Yit" == Khoo Yit Phang <khooyp@cs.umd.edu> writes:
> 
> Tom> Rather than use a global, it seems a bit better to me to store the old
> Tom> signal handler in the python_env, and then restore it from there.
> 
> Yit> Actually, that's not the behavior I'm going for: instead of restoring
> Yit> the old signal handler, I'm preserving whatever changes to the signal
> Yit> handler that has been made in the nested Python context (if it can
> Yit> ever happen).
> 
> Ok, I see.  I am not convinced that this is the best approach; but I am
> also not sure that the situation can arise.

I don't know GDB's code base well enough to know if there are commands that can affect signal handling in subsequent commands, e.g., (as a contrived example, since it works correctly, I think), "handle SIGINT print". If so, then gdb.execute("handle SIGINT print") should preserve the handler. This is the "safer" behavior, that's my reasoning.

> Yit> I think it's okay to handle just the long-running python->gdb
> Yit> transitions, or those where SIGINT is critical to correct
> Yit> functionality. Are there other long-running python->gdb transitions
> Yit> that I should fix?
> 
> It is hard to say without auditing them.
> 
> Your logic here seems reasonable enough to me, though.
> 
> I think it is tempting to set quit_flag in your new signal handler, but
> I think that just leaves the problem of deciding when to clear it.
> 
> One thought is to have a new PY_TRY_CATCH macro that does "the right
> thing", say by setting and resetting the signal handlers.  Then you
> could fix the problem with sed in python/*.[ch].
> 
> This may require some hackery in exceptions.[ch], I am not sure.
> If we're willing to do that then maybe there could be a variant of
> TRY_CATCH that just resets quit_flag when finished, the idea being that
> in Python code, either quit_flag is handled by throwing a gdb exception,
> or a Python exception is set, which will be converted.
> 
> That seems a bit too magical, but anyway I think a comprehensive
> solution is doable with some thought.

If I understand correctly, you're thinking of how to handle Ctrl-C that occurs in a Python context that should be treated as an interrupt in an outer GDB context, right? I think rather than setting quit_flag in the signal handler, we can catch KeyboardInterrupt after "python" returns, then set quit_flag there.

Likewise, we should to check quit_flag when gdb.execute (or other commands) return, and raise KeyboardInterrupt (or some subclass). This is where PY_TRY_CATCH comes in, right?

Yit
July 25, 2012