C-c (KeyboardInterrupt) hangs pudb when running event loop

[craftyguy]

I am using a library (https://github.com/getsenic/gatt-python/blob/master/gatt/gatt_linux.py) that implements its own event loop. When I call the .run() method in this library, eventually I would like to interrupt it, but it seems that pudb does not either pass through the interrupt or gets hung up itself. This is printed to the console when running an app using this library after it has called .run(), when running with pudb:

^CTraceback (most recent call last):
  File "/home/clayton/src/ride_track/venv/lib/python3.7/site-packages/gi/_ossighelper.py", line 107, in signal_notify
    if condition & GLib.IO_IN:
  File "/home/clayton/src/ride_track/venv/lib/python3.7/site-packages/gi/_ossighelper.py", line 107, in signal_notify
    if condition & GLib.IO_IN:
  File "/usr/lib64/python3.7/bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "/home/clayton/src/ride_track/venv/lib/python3.7/site-packages/pudb/debugger.py", line 189, in dispatch_line
    raise bdb.BdbQuit
bdb.BdbQuit

I basically have to C-z to background the task and then send SIGKILL to get pudb to quit (which is obviously not ideal).

I'll try to poke around some more to figure out what might be going on here, but figured I would file this issue just in case I am doing something obviously incorrect.

[inducer]

We do have a signal handler for ^C in an attempt to do something smarter than just show where the KeyboardInterrupt exception brought things to a halt. If you have suggestions (PRs :) that would improve the behavior of this in your situation, I'm happy to consider them.

[asmeurer]

Probably the signal handler should not be used at all if threads are involved. I don't have much knowledge of how threading works in Python, though, so I'm not sure how to do this.