Will python ever have signalhandlers in threads?

[Fernando Perez]

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
        self.ready.acquire()

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

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

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

        # We're done with thread-protected variables
        self.ready.release()
        # 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.

Best,

f