The nanny process is ultimately  the way we need to go, otherwise you won't ever be able to interrupt remote kernels.<br><br><div class="gmail_quote">On Thu, Feb 23, 2012 at 23:04, Matt Terry <span dir="ltr"><<a href="mailto:matt.terry@gmail.com">matt.terry@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I want to be able to interrupt an ipython kernel that is local to my<br>
machine, but not owned by the current process.  I recognize that the<br>
general problem of interrupting a truly remote kernel is a harder<br>
problem and i'm not explicitly not addressing that.  However, I think<br>
interrupting a local kernel is worth having a special case.<br>
<br>
All you need to interrupt a local kernel is its pid, so you can send a<br>
SIGINT to the appropriate process.  The only way I can think of to get<br>
that information is to ask the remote kernel (over the shell channel)<br>
to return the output of "os.getpid()".  The kernel might restart and<br>
change pid, so you'd have to poll.  This seems ugly and failure prone.<br>
<br>
What you need is<br>
A) the kernel to have a nanny that always knows what the kernel's pid is<br>
or<br>
B) the kernel to communicate its pid someway other than over the shell channel<br>
<br>
What about using the heartbeat channel to echo the pid?  To my<br>
understanding, the heart beats even if the kernel is chugging away.<br>
We could have the heartbeat channel return the pid instead of the<br>
uuid, or we could return them both.  Alternatively, we could pid<br>
information in a file in .ipython/somewhere, but that seems<br>
potentially contentious.<br>
<br>
-matt<br>
_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</blockquote></div><br>