[SciPy-dev] gui_thread issue

eric jones eric at enthought.com
Mon Nov 8 00:43:51 CST 2004

Fernando Perez wrote:

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


    In [5]: signal.getsignal(signal.SIGINT)
    Out[5]: <built-in function default_int_handler>
    In [6]: import gui_thread
    In [7]: gui_thread.start()
    In [8]: signal.getsignal(signal.SIGINT)

How do you like them apples!  Not sure if I'll have a chance to chase 
this down right now, but I am glad to know where to start looking...


More information about the Scipy-dev mailing list