Will python ever have signalhandlers in threads?
Fernando Perez
fperez528 at yahoo.com
Fri Nov 12 12:44:33 EST 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
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
More information about the Python-list
mailing list