Will python ever have signalhandlers in threads?

[Jean Brouwers]

Fernando,

Just curious, does 'gtk/WX' in your message below mean wxPython?

If so, does this signal handling code actually work with wxPython?

/Jean Brouwers


In article <mailman.6310.1100281534.5135.python-list at python.org>,
Fernando Perez <fperez528 at yahoo.com> wrote:

> 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
>