<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 25, 2011, at 11:47 AM, Thomas Kluyver wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On 25 May 2011 17:20, Evan Patterson <span dir="ltr"><<a href="mailto:epatters@enthought.com">epatters@enthought.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I am wondering why this should be necessary at all, though. Shouldn't the kernel process always trap Ctrl+C signals at some point to prevent them from hosing the kernel? I've actually had a few problems with this myself. Sometimes when I interrupt the kernel from the Qt console, the whole kernel goes down.</blockquote>

</div><br>It's when the frontend is accepting input - so Ctrl-C should just give you a clean prompt, without sending anything to the kernel. We could catch the exception in the kernel and ignore, but it doesn't feel like the right way to do it. I'd prefer to arrange it so that the signal from the user hitting Ctrl-C doesn't reach the kernel at all.<br></blockquote></div><br><div>The way interrupts work in the Qt console (in Unix) is precisely that, though: the frontend process sends a SIGINT signal to the kernel. The expectation is that the kernel will handle the signal in a reasonable way. We could try to devise some other scheme, like I did for Windows, but it would be difficult to get right. The kernel should just do the right thing.</div><div><br></div><div>Evan</div></body></html>