This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/4]: Handle SIGINT under Python by raising KeyboardInterrupt
>>>>> "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