Add autorestart logic to the kernel managers #2873
Conversation
It was a property, but it is better suited as a method now. Added tests in both the KM and MKM case.
| # This restart event should leave the connection file in place so | ||
| # the ports are the same. Because this takes place below the | ||
| # MappingKernelManager, the kernel_id will also remain the same. | ||
| self.log('KernelRestarter: restarting kernel') |
There was a problem hiding this comment.
this probably wants to be self.log.info, not self.log
|
why is the autorestart only for MKM? That doesn't make sense to me. |
|
You mean why not put it into the KernelManager itself? Honestly not sure.
But there are reasons to include the logic in KM itself:
Thoughts? It is easy to move this around at this point... On Fri, Feb 1, 2013 at 11:20 AM, Min RK [email protected] wrote:
Brian E. Granger |
|
Summary of discussion on IRC: restart logic belongs in KM, MKM should remain strictly a multiplexer. eventloop implementation of the restart is up to subclasses (e.g. Qt signal, etc.) |
|
this is superseded by #3011 |
Currently, when kernels die in the notebook, the user is prompted and asked if they want to restart the kernel. This is problematic from a number of standpoints:
In this PR, I have added a new KernelRestarter object that works alongside a KernelManager object to poll the kernel's subprocess and call KernelManager.restart_kernel if it dies. I am also changing how the user is notified of this event.
Remaining: