[IPython-dev] about ipython-zmq

[Brian Granger]

On Sun, Jul 25, 2010 at 3:55 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Sun, Jul 25, 2010 at 2:38 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> >
> > I think it is a little dangerous to forward Ctrl-C.  When there are two
> > processes like this I think it is very ambiguous as to what it means.  I
> > would rather go with a frontend magic:
> > :kernel 0 kill
>
> I really think we do need Ctrl-C.  It would be pretty awful to have an
> interactive environment (especially for the line-based, blocking ones
> like the plain terminal Omar is working on and Evan's) where Ctrl-C
> doesn't just stop the kernel, at least on platforms where we can send
> processes signals.  Given that the frontend does no real computation,
> what other semantics should Ctrl-C have?
>
>
The case that I am worried about is if a frontend hangs.  Almost *Everyone*
will try Ctrl-C to try to kill the frontend, but if the frontend is enough
alive to trap Ctrl-C and send it to the kernel, the kernel will get it
instead.  If the kernel is running code, it is likely that someone will be
unhappy.  This is especially true because of the possibility of multiple
frontends running the same kernel.

Like most GUI applications (and Mathematica for example), I think Ctrl-C
should be disabled and the frontend should provide a different interface
(possibly using a kernel magic) to signal the kernel.  But let's talk more
about this.


> >> In order to do this, you'll  need to know the PID of the kernel
> >> process, but Evan has already been making progress in this direction
> >> so you can benefit from his work.  This code:
> >>
> >>
> >>
> http://github.com/epatters/ipython/blob/qtfrontend/IPython/zmq/kernel.py#L316
> >>
> >> already has a kernel launcher prototype with the necessary PID
> >> information.
> >>
> >
> > Let's start to use the Popen interface of Python 2.6.  It has a terminate
> > and kill method that gets around the PID stuf in a cross platform manner.
>
> subprocess kill only sends SIGKILL, while os.kill allows the sending
> of any signal, so I'm not sure it completely replaces os.kill for us.
> But for subprocess cleanup then yes, I'm all for using it (especially
> if it works reliably in Windows).
>
>
True, and we do probably want to allow Linux and Mac to send the other
signals.

Brian


> Cheers,
>
> f
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20100725/8a8c66ac/attachment.html>