<br><br><div class="gmail_quote">On Sun, Jul 25, 2010 at 6:29 PM, Fernando Perez <span dir="ltr"><<a href="http://fperez.net">fperez.net</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sun, Jul 25, 2010 at 5:57 PM, Brian Granger <<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a>> wrote:<br>
> The case that I am worried about is if a frontend hangs.  Almost *Everyone*<br>
> will try Ctrl-C to try to kill the frontend, but if the frontend is enough<br>
> alive to trap Ctrl-C and send it to the kernel, the kernel will get it<br>
> instead.  If the kernel is running code, it is likely that someone will be<br>
> unhappy.  This is especially true because of the possibility of multiple<br>
> frontends running the same kernel.<br>
> Like most GUI applications (and Mathematica for example), I think Ctrl-C<br>
> should be disabled and the frontend should provide a different interface<br>
> (possibly using a kernel magic) to signal the kernel.  But let's talk more<br>
> about this.<br>
<br>
</div>A terminal is a good example of a gui application that forwards Ctrl-C<br>
to the underlying process it exposes.  When you type Ctrl-C in a<br>
terminal, it's not the terminal itself (say xterm or gnome-terminal)<br>
that gets it, but instead it's sent to whatever you were running at<br>
the time.<br>
<br></blockquote><div><br></div><div>Yes, definitely.  On Mac OS X, as far as I know the terminal is the only application that maps Ctrl-C to SIGINT.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

It makes perfect sense to me for IPython frontends to forward that<br>
signal to the kernel, since frontends are thin 'handles' on the kernel<br>
itself, and interrupting a long-running computation is one of the most<br>
common things in everyday practice.<br>
<br>
I know it would drive me positively insane if I had to type a full<br>
command to send a simple interrupt to a running kernel.  In full GUI<br>
frontends we can certainly expose a little 'interrupt kernel' button<br>
somewhere, but I suspect I wouldn't be the only one driven mad by<br>
Ctrl-C not doing the most intuitive thing...<br>
<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The case of a hung frontend should be handled like other apps: a close<br>
button, a 'force quit' from the OS, etc.  Killing a hung gui in<br>
general is done like that, and it should be indeed a special 'kill'<br>
operation because in general, the front ends should not be hung under<br>
normal conditions: they run very little code, so there's no reason for<br>
them to block other than when they are waiting for a kernel to return.<br>
<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Now, for *asynchronous* frontends, then we certainly want an<br>
'interrupt kernel' command/button, so Gerardo probably should<br>
implement something like that.  But a blocking, line-based frontend<br>
that 'feels like a terminal' should 'act like a terminal', I think...<br>
<br></blockquote><div><br></div><div>Yes I agree with that, definitely.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Cheers,<br>
<font color="#888888"><br>
f<br>
</font></blockquote></div><br>Cheers,<div><br></div><div>Brian<br clear="all"><br>-- <br>Brian E. Granger, Ph.D.<br>Assistant Professor of Physics<br>Cal Poly State University, San Luis Obispo<br><a href="mailto:bgranger@calpoly.edu">bgranger@calpoly.edu</a><br>
<a href="mailto:ellisonbg@gmail.com">ellisonbg@gmail.com</a><br>
</div>