[IPython-dev] about ipython-zmq

Brian Granger ellisonbg at gmail.com
Sun Jul 25 21:59:25 EDT 2010

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

> On Sun, Jul 25, 2010 at 5:57 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
> > 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.
> A terminal is a good example of a gui application that forwards Ctrl-C
> to the underlying process it exposes.  When you type Ctrl-C in a
> terminal, it's not the terminal itself (say xterm or gnome-terminal)
> that gets it, but instead it's sent to whatever you were running at
> the time.
Yes, definitely.  On Mac OS X, as far as I know the terminal is the only
application that maps Ctrl-C to SIGINT.

> It makes perfect sense to me for IPython frontends to forward that
> signal to the kernel, since frontends are thin 'handles' on the kernel
> itself, and interrupting a long-running computation is one of the most
> common things in everyday practice.
> I know it would drive me positively insane if I had to type a full
> command to send a simple interrupt to a running kernel.  In full GUI
> frontends we can certainly expose a little 'interrupt kernel' button
> somewhere, but I suspect I wouldn't be the only one driven mad by
> Ctrl-C not doing the most intuitive thing...
Good points.  I do agree that if a frontend looks like a terminal and acts
like a terminal, then it should *really* act like a terminal and use Ctrl-C
in the same way as a terminal.  For frontends that are less terminal like, I
am less convinced, but this is partly because I haven't really interacted
with Python in this way.  I think this will become more clear as we move
forward.  My only hesitation about Ctrl-C in a GUI app is the ambiguity of
what Ctrl-C does in a distributed application.  But, I do think we want to
err in the direction of making it easy to interrupt things, so Ctrl-C makes
the most sense for the default.  There is nothing worse than starting up an
app and having Ctrl-C disabled when it seems like it should be active.  But,
I do think it would be nice to have this configurable.

> The case of a hung frontend should be handled like other apps: a close
> button, a 'force quit' from the OS, etc.  Killing a hung gui in
> general is done like that, and it should be indeed a special 'kill'
> operation because in general, the front ends should not be hung under
> normal conditions: they run very little code, so there's no reason for
> them to block other than when they are waiting for a kernel to return.
True, a hung frontend should be exceptional whereas interrupting code in the
kernel is common.  And you are right that a hung application should be
handled like other hung applications.

> Now, for *asynchronous* frontends, then we certainly want an
> 'interrupt kernel' command/button, so Gerardo probably should
> implement something like that.  But a blocking, line-based frontend
> that 'feels like a terminal' should 'act like a terminal', I think...
Yes I agree with that, definitely.

> 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/fb2616d3/attachment.html>

More information about the IPython-dev mailing list