<br><br><div class="gmail_quote">On Fri, Oct 8, 2010 at 15:52, 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 Fri, Oct 8, 2010 at 3:41 PM, MinRK <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>> wrote:<br>
> It doesn't necessarily have to be done differently at startup, because you<br>
> can 'destroy' a widget at any point, leaving the process alive.<br>
<br>
</div>Sorry, do you mean leaving the client process or the kernel process alive?<br></blockquote><div><br></div><div>It leaves the parent process alive, but destroys the widget.  What would require some different behavior at the top level would be to allow the kernel to persist beyond its parent process.  The original KernelManager lives in that process. I haven't changed this behavior at all, I just destroy the window *without* ending the process.  Then, when another window issues a shutdown command, the original parent process gets shutdown as well as the kernel subprocess.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> I just updated my keepkernel branch with a couple things:<br>
> 1) fixed error when resetting pykernel (it still reset, but printed an<br>
> error)<br>
> 2) fixed issue where closing a frontend, even secondary ones, always<br>
> shutdown the kernel<br>
> 3) shutdown_reply now goes out on the pub socket, so all clients are<br>
> notified<br>
>    3.a) this means that all clients can (and do) refresh the screen when a<br>
> reset is called, just like the master frontend<br>
> 4) kernel can stay alive after consoles are shutdown, and can be shutdown by<br>
> any frontend at any point<br>
>    4.a) this means that a shutdown request from any frontend can close all<br>
> open frontends and the kernel, even if the kernel is detached, leaving no<br>
> processes zombified.<br>
>    4.b) 4.a required that a 'reset' element be added to<br>
> shutdown_request/reply messages to identify the difference between a real<br>
> shutdown message and stage 1 of a reset.<br>
> <a href="http://github.com/minrk/ipython/commits/keepkernel/" target="_blank">http://github.com/minrk/ipython/commits/keepkernel/</a><br>
<br>
</div>Great!  Do you want this for inclusion now?  Initially you meant it<br>
purely as a proof of concept, but at this point it's getting to be<br>
useful functionality :)<br></blockquote><div><br></div><div>It can be merged now. The main thing that's not solid is the close dialog.  It's not obvious to me how to present the options clearly and concisely.</div>

<div><br></div><div>Any suggestions for prompt and button text?</div><div>Cancel: do nothing (easy)</div><div>Option 1: close only the console</div><div>Option 2: shutdown the entire session, including the kernel and all other frontends.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
I'll trade you a review for a review of my current pull request, that<br>
fixes and cleans up ton of nasty execution logic:<br>
<br>
<a href="http://github.com/ipython/ipython/pull/163" target="_blank">http://github.com/ipython/ipython/pull/163</a></blockquote><div><br></div><div>Sure, I'll start looking it over now.  Mine's here: </div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>

<br></div><div><a href="http://github.com/ipython/ipython/pull/164">http://github.com/ipython/ipython/pull/164</a></div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
<br>
:)  The key question in yours is whether it leaves the Qt client<br>
process zombified or not, I'm not quite clear on that point yet.<br></blockquote><div><br></div><div>Nothing really gets zombified, because the original kernel does not get detached from its parent.  If you close all the consoles, you can still stop the kernel with ctrl-C in the original terminal window.</div>

<div><br></div><div>However, if you start the original kernel with a GUI launch method (i.e. not attached to a terminal), you can close all of the consoles, leaving the kernel around waiting for frontends.  This is sort of like a zombie since there is little evidence that it's still around, but it's still fully functional and fully valid (you can connect frontends to it later). Note that you have to specifically choose to leave the kernel alive every time you close a console to do this, so I'm okay with that level of clarity.</div>

<div><br></div><div>There could be something wrong in my code, since this (and the fixes yesterday) is my first Qt code ever, but it seems pretty straightforward.</div><div><br></div><div>-MinRK</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<br>
cheers,<br>
<font color="#888888"><br>
f<br>
</font></blockquote></div><br>