Will python ever have signalhandlers in threads?

Fernando Perez fperez528 at yahoo.com
Fri Nov 12 18:44:33 CET 2004

Antoon Pardon wrote:

> Op 2004-11-09, Antoon Pardon schreef <apardon at forel.vub.ac.be>:
>> I have had a look at the signal module and the example
>> and came to the conclusion that the example wont work
>> if you try to do this in a thread.
>> So is there a chance similar code will work in a thread?
> Well I guess that the lack of response means the anser is:
>   Not likely.

Sorry that I don't have time to go through the code you mention, but recently
for ipython I had to deal with signal handling in threads.  You can look in
IPython's Shell.py for the hacks I ended up using, if you care.

The gist of it is this function, which gets installed into a gtk/WX timer:

    def runcode(self):
        """Execute a code object.

        Multithreaded wrapper around IPython's runcode()."""

        # lock thread-protected stuff

        # Install sigint handler
        signal.signal(signal.SIGINT, sigint_handler)

        if self._kill:
            print >>Term.cout, 'Closing threads...',
            for tokill in self.on_kill:
            print >>Term.cout, 'Done.'

        # Run pending code by calling parent class
        if self.code_to_run is not None:
            # Flush out code object which has been run
            self.code_to_run = None

        # We're done with thread-protected variables
        # This MUST return true for gtk threading to work
        return True

As you see, I ended up installing the handler on *every* invocation of the
function, after taking a lock.  I couldn't find how to assign the handler to
the thread, so this was my brute-force approach.

This is incredibly ugly, and there may be a better solution.  But in this
particular case, the hack works and the penalty is not noticeable to end users.



More information about the Python-list mailing list