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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "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.

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.

Tom