[SciPy-dev] gui_thread issue

[Fernando Perez]

eric jones wrote:
>>One more thing.  Now that I have the necessary "readline" module in my 
>>site-packages to make ipython colorize correctly, Ctrl-Z no longer 
>>works to exit a standard python shell or ipython.  Has anyone else had 
>>similar problems?  Ctrl-C sometimes exits ipython, sometimes not.  I 
>>use "import sys;sys.exit()" to exit standard python prompts.
>>
> 
> I was a little off here.  Ctrl-Z doesn't work with either ipython.py or 
> the standard python shell.
> 
> In ipython, Ctrl-C generates a keyboard interrupt in ipython.py *unless* 
> I have imported gui_thread and started it.  Then it kills the session. 
> 
> Here is an example of what I get:
> 
> C:\wrk\converge\src\lib\enthought\tvtk\examples>ipython.py
> Python 2.3.3 (#51, Feb 16 2004, 04:07:52) [MSC v.1200 32 bit (Intel)]
> <snip>
> In [1]: <Ctrl-C>
> KeyboardInterrupt
> In [1]: import gui_thread
> In [2]: <Ctrl-C>
> KeyboardInterrupt
> In [2]: gui_thread.start()\
> In [3]: <Ctril-C>
> C:\wrk\converge\src\lib\enthought\tvtk\examples>
> 
> So, it looks like gui_thread changes the way <Ctrl-C> behaves.  Anyone 
> know of a fix for this (and the Ctrl-Z issue)?

gui_thread (or one of the modules it pulls in) might be installing a signal 
handler to trap SIGINT.  Note that under linux, I don't see this behavior at 
all: Ctrl-C works as expected both before AND after starting gui_thread.  So 
it may be a windows thing.  Could you try the following please:

In [1]: import signal

In [2]: signal.getsignal(signal.SIGINT)
Out[2]: <built-in function default_int_handler>

In [3]: import gui_thread

In [4]: gui_thread.start()

In [5]: signal.getsignal(signal.SIGINT)
Out[5]: <built-in function default_int_handler>

This will tell you, before and after gui_thread starts, what the SIGINT signal 
handler is, and if gui_thread changed it in any way.  If there is no change in 
the return value of the SIGINT handler, then it means that gui_thread is 
somehow messing up signal handling across threads (which wouldn't surprise me, 
after the nasty hacks I've just gone through in ipython precisely to deal with 
signals and threads for matplotlib).

One thing I've learned recently, is that in python, the moment you throw 
threads in the picture, both signals and exceptions become a hell of a pain.

Cheers,

f