[SciPy-dev] gui_thread issue

[eric jones]

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

Hah!

    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)
    <SEG-FAULT>
    C:\temp\VTKData\Data>

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

thanks,
eric