Connect to existing Local Kernel

[DonJayamanne]

FYI - This feature is for the scratch pad path.

Connecting to exiting live remote kernels is simple:

• When we detect remote kernels we create a controller for that live remote kernel
• Then we select that remote kernel controller in a notebook/IW

For local kernels, we have no such concept - we must create a controller that points to the live local kernel.
Suggestions

• Option 1: When we start a kernel, we could then create a controller that points to this active kernel (similar to live remote kernels)
• Option 2: When starting a scratch pad, we can first create the controller and then attach the controller to the notebook

Notes:

• How can user start a notebook that points to the same local live kernel?
  • We need option 1 for this.
• How can user start an IW that points to the same local live kernel?
  • We need option 1 for this.
• What is the life time of this controller?
  • Rmemeber - this is a local live kernel.
  • If all notebooks/IW that connect to this controller are closed, then kill off the kernel (as is done today) & delete this controller.
  • However if the kernel was originally started by a 3rd party exetnsion then don't do anything (in that case the lifetime of the kernel/controller is managed by the 3rd party extension).
  • If the kernel dies (3rd party closes this or we kill it), then remove the controller from the list (e.g. if user kills the kernel from kernel management UI).
• Do we have multiple IKernel instances?
  • No, we'll have just the one IKernel instance.
• Where do we list these live local kernels
  • Just as with live remote kernels, we'll have a separate section for live local kernels.
• Interrupts/restarts/cell execution all share the same kernel
  • Thus if we restart the kernel in scratch pad, that will restart the kernel in the other notebook/iw (where the kernel was originally started)
  • Similarly execution in scratch pad will end up getting queued along with the other cells. I.e. if we have a few cells running in the original notebook, and we create a scratch pad, and run cells in this scratch pad, they will end up getting queued in the same queue (after all its the same kernel).

Thoughts:

• Go with option 2, if and when users ask for option 1, we can add support for that
• Even with Option 2, we still need to create an controller and display it in the list (meaning we still need an entry under Live Local Kernels), which is the same as Option 1. However this controller is created only when creating a scratch pad (we'll expose a simple API or simple command to make this possible in Jupyter ext).

[DonJayamanne]

Outcome:

• When connecting to a local kernel add an entry for the live local kernel in kernel list (for insiders)
• If we connect to a live local kernel and the original notebook/iw is closed, then kill off the corresponding kernel
  • If users complain we can change this later

For now, enable this feature only in the pre-release (insider version).