I've got a lot of feedback from the users of our JupyterLab deploy mentioning the fact that kernels being still running when they close a notebook was counterintuitive.
A reference could be kept for each widget using the kernel, and with the count of references decreasing to 0, the kernel could be automatically shut down to save resources. A nice addition to this behavior could be to be able to "pin" a kernel to keep it running regardless of it having widgets attached.
What's the rationale and/or the technical or UX reasons to have such a behavior?
CC @ellisonbg
Probably the strongest reason for this behavior is to match that of the
classic notebook.
I know that isn't a very compelling UX reason, but there are a few others:
We do want to avoid stopping a kernel that is actively working or has
previously computed something. Kernels are (deliberately) stateful and that
state can take long times to re-compute from scratch (many hours, days,
etc.) and is not durable. Stopping a kernel without the users explicit
action would essentially be throwing their work away without their
permission. I don't know of any way assess whether or not the current state
of the kernel is valuable to a user or not.
If the kernels state was durable (for example stored in a database at all
times) that would be quite different - then we could try to assess if a
kernel is actively computing something new. I don't know of any kernel that
has durable state.
I agree that it is a bit of a pain to have to shutdown kernels by hand.
However, I think that is an OK tradeoff given potential consequences of
killing a kernel.
One possibility would be to write a JupyterLab extension that automatically
shuts down kernels (optionally) if lab detects you haven't used them
interactively for a (configurable) period of time, and ask for
confirmation. That could be useful in some situations. I just don't think
that can be the default setting for users.
On Tue, Apr 24, 2018 at 3:06 PM, Jason Grout notifications@github.com
wrote:
CC @ellisonbg https://github.com/ellisonbg
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jupyterlab/jupyterlab/issues/4454#issuecomment-384095295,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABr0OJ2LESCWwue8qPV7p1SXyzJek6Aks5tr6HTgaJpZM4Tifij
.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]
I think lab could need a setting for this. And then a general procedure for promoting the user for behavior if a setting has not been set, with an option "remember my choice". This pattern could be a useful tiebreaker for a lot of cases.
Most helpful comment
I think lab could need a setting for this. And then a general procedure for promoting the user for behavior if a setting has not been set, with an option "remember my choice". This pattern could be a useful tiebreaker for a lot of cases.