KeyboardInterrupt and threading

[Anand Pillai]

There is an easier way than using signals.

Add a keyboard interrupt handler for your main function.
And in the handler code, write a clean up function which
will be able to then manage threads.

This is the method I have used in my HarvestMan program.
I am copying this code here.

------------(copied code)----------------------------------------
            try:
                self.start_project()
            except (KeyboardInterrupt, EOFError):
                # Localise links
                if not self._cfg.ignorekbinterrupt:
                    # dont allow to write cache, since it
                    # screws up existing cache.
                    GetObject('datamanager').conditional_cache_set()
                    self.clean_up()
---------------------------------------------------------------------

The clean_up method takes care of cleaning the thread.
There you can add code to pass on the interrupt to the
main thread or perform your own clean up actions.

One way to do this is to use the currentThread() method
of threading module which can tell you whether the thread
is the main or a worker. 

One drawback with this method is that you might need to
set your threads as 'daemon' threads to make sure that
the threads dont hang your python program. This is because
the entire python program exits when the only threads left
are daemon threads.

-Anand

q2n8byu02 at sneakemail.com (Ivan Nestlerode) wrote in message news:<a6562e06.0401071814.7f02ab1b at posting.google.com>...
> Michael Hudson <mwh at python.net> wrote in message news:<m3k7442b9r.fsf at pc150.maths.bris.ac.uk>...
> > This is hard for me to answer -- it works fine for me.  What platform
> > are you on?  ISTR Debian, but not versions of anything.
> > 
> > I'm somewhat inclined to start blaming libc at this point...
> > 
> > As you may well be aware, the combination of threads and signals is a
> > bit of a minefield.  Python runs all threads other than the main
> > thread with all signals masked. My understanding is that when a signal
> > is delivered to a process it's delivered to an arbitrary thread that
> > has that signal unmasked -- in Python's case, this should be the main
> > thread.  It kind of sounds like in your case the signal is being
> > queued up on a non-main thread, but as the signal is never unblocked,
> > it never gets handled.
> > 
> > [...]
> > > I think this is a bug though (I shouldn't have to put hacks into the
> > > main thread to get this to work).
> > 
> > Agreed, but I'm not sure they're in Python.
> > 
> > > Any thoughts?
> > 
> > Upgrade glibc?
> > 
> > Cheers,
> > mwh
> 
> I've filed the bug with Debian since I think it is something wrong
> with their Python or their glibc. The bug is #226547.
> 
> FYI, here are the exact details of the kernel/packages that don't seem
> to work:
> 
> $ uname -a
> Linux debian 2.4.23 #1 Sun Nov 30 21:11:49 EST 2003 i686 GNU/Linux
> 
> packages and versions:
> ii  libbz2-1.0                1.0.2-1
> ii  libc6                     2.3.2.ds1-10
> ii  libdb4.1                  4.1.25-10
> ii  libncurses5               5.3.20030719-4
> ii  libreadline4              4.3-8
> ii  libssl0.9.7               0.9.7c-5
> ii  python                    2.3.3-4
> ii  python2.3                 2.3.3-4
> ii  zlib1g                    1:1.2.1-3
> 
> 
> -Ivan