[IPython-dev] New ipythonqt console questions/feedback

MinRK benjaminrk at gmail.com
Fri Oct 8 19:09:34 EDT 2010


On Fri, Oct 8, 2010 at 15:52, Fernando Perez <fperez.net at gmail.com> wrote:

> On Fri, Oct 8, 2010 at 3:41 PM, MinRK <benjaminrk at gmail.com> wrote:
> > It doesn't necessarily have to be done differently at startup, because
> you
> > can 'destroy' a widget at any point, leaving the process alive.
>
> Sorry, do you mean leaving the client process or the kernel process alive?
>

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.


>
> > I just updated my keepkernel branch with a couple things:
> > 1) fixed error when resetting pykernel (it still reset, but printed an
> > error)
> > 2) fixed issue where closing a frontend, even secondary ones, always
> > shutdown the kernel
> > 3) shutdown_reply now goes out on the pub socket, so all clients are
> > notified
> >    3.a) this means that all clients can (and do) refresh the screen when
> a
> > reset is called, just like the master frontend
> > 4) kernel can stay alive after consoles are shutdown, and can be shutdown
> by
> > any frontend at any point
> >    4.a) this means that a shutdown request from any frontend can close
> all
> > open frontends and the kernel, even if the kernel is detached, leaving no
> > processes zombified.
> >    4.b) 4.a required that a 'reset' element be added to
> > shutdown_request/reply messages to identify the difference between a real
> > shutdown message and stage 1 of a reset.
> > http://github.com/minrk/ipython/commits/keepkernel/
>
> Great!  Do you want this for inclusion now?  Initially you meant it
> purely as a proof of concept, but at this point it's getting to be
> useful functionality :)
>

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.

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


> I'll trade you a review for a review of my current pull request, that
> fixes and cleans up ton of nasty execution logic:
>
> http://github.com/ipython/ipython/pull/163


Sure, I'll start looking it over now.  Mine's here:

http://github.com/ipython/ipython/pull/164



>
> :)  The key question in yours is whether it leaves the Qt client
> process zombified or not, I'm not quite clear on that point yet.
>

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.

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.

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.

-MinRK


> cheers,
>
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20101008/b4236d5c/attachment.html>


More information about the IPython-dev mailing list