KeyboardInterrupt and threading

[Ivan Nestlerode]

Hello comp.lang.python,

I am attempting to write a threaded program right now in Python
(version 2.3 on Debian unstable) and the current behavior of
KeyboardInterrupt is causing me grief. From the documentation of the
thread module in Python 2.3.3:

"Threads interact strangely with interrupts: the KeyboardInterrupt
exception will be received by an arbitrary thread. (When the signal
module is available, interrupts always go to the main thread.)"

So the current behavior is that some "arbitrarily chosen" thread
receives the KeyboardInterrupt exception when the user hits Ctrl-C. My
question is whether there is some way to always make the main thread
receive the KeyboardInterrupt. The snippet at the end of the
documentation is vague/confusing. It sounds like KeyboardInterrupt
would always be delivered to the main thread, but I have tested this
and it is definitely not behaving that way. Maybe it just means that
the Unix signal is received by the main thread's signal handler (and
at that point an arbitrary thread is picked for KeyboardInterrupt). I
don't know.

The reason I cannot use the current "arbitrary thread"
KeyboardInterrupt delivery model:

The current model seems to deliver the KeyboardInterrupt to the
busiest thread (i.e. some sub-thread doing lots of computation, as
opposed to my main thread that is sitting in a sleep() loop). This
causes problems because the busy thread that I spawn runs library code
that was not written by me. That library code may contain lines like
"except:" that mask the KeyboardInterrupt so that the user experience
is that the app seems to ignore Ctrl-C.

If I could guarantee delivery of KeyboardInterrupt to the main thread,
I could control things much more easily/consistently. With the current
semantics code reuse becomes very difficult (I cannot use any code
that is "sloppy" with its exception catching or Ctrl-C will be
ignored).

Any ideas (besides rewriting the sloppy library code) would be much
appreciated.

Thanks,
-Ivan