Allow multi kernel manager to handle asynchronous start kernel #402
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MetaKernelFinder -> KernelFinder
Prototype new kernel discovery machinery
Fix typo in documentation.
The old URL points to a "This page has moved"-page
Updated URL for Jupyter Kernels in other languages
- use IOLoop.current over IOLoop.instance - drop removed `loop` arg from PeriodicCallback - deprecate now-unused IOLoopKernelRestarter.loop
- interrupt_mode="signal" is the default and current behaviour - With interrupt_mode="message", instead of a signal, a `interrupt_request` message on the control port will be sent
prepare for tornado 5
Additional to the actual signal, send a message on the control port
this should allow ipykernel's wheel-installed specs to specify `python3` or `python2` and prevent python2 kernels from launching with sys.executable if the Python version is 3.
A simple lead in to the 'kernel nanny' work, this adds a command so you can do: jupyter kernel --kernel python
update python version testing
The license requires that all copies of the software include the license. This makes sure the license is included in the wheels. See the wheel documentation [here](https://wheel.readthedocs.io/en/stable/#including-the-license-in-the-generated-wheel-file) for more information.
Include LICENSE file in wheels
Don't include extra buffers in message signature
Update gitignore configuration
This removes special treatment of IPython console so that other kernels can get command-line args. This doesn't allow the passing of flags, but does allow filenames, etc. Once this fix is in place, kernels can get these args via self.parent.extra_args
Allow third-party kernels to get additional args
Remove commented debug statement that used old API.
Try to fix coverage
Carreau
force-pushed
the
async-km
branch
3 times, most recently
from
08054e3
to
8d474c1
Compare
This is a work in progress to allow asynchronous start of kernels, typically kernel that will be submitted via job queue and for which you do not know (yet), the host on which they will be running. This is work in progress, but I'm suspecting we want to push for async methods in a lot of place, and there is imho no hard in making them async as they don't _have to_ yield. We can't (AFAICT) change start_kernel to be async as this would be a change of API for our consumers.
kevin-bates
reviewed
Jan 24, 2019
| # this looks weird as we are extra indented, but we are | ||
| # indeed defining a conditional method depending on the version | ||
| # of Python. | ||
| MultiKernelManager.start_kernel_async = start_kernel_async |
There was a problem hiding this comment.
Should this be
MultiKernelManager.start_kernel = start_kernel_asyncOtherwise, it's not clear to me how start_kernel_async() would get invoked - unless there's some python magic happening that is beyond my limited experience.
kevin-bates
added a commit
to kevin-bates/jupyter_client
that referenced
this pull request
Feb 16, 2019
Inspired by jupyter#402, but needing support for python 2.7, these changes essentially apply the same model used in Notebook for supporting coroutines with appropriately placed yield statements in order to start multiple kernels simultaneously with the same server instance.
kevin-bates
added a commit
to kevin-bates/jupyter_client
that referenced
this pull request
Feb 19, 2019
Inspired by jupyter#402, but needing support for python 2.7, these changes essentially apply the same model used in Notebook for supporting coroutines with appropriately placed yield statements in order to start (and restart) multiple kernels simultaneously within the same server instance.
SylvainCorlay
force-pushed
the
master
branch
from
b1fe8e4
to
3e8ee4a
Compare
|
@Carreau this will need a rebase since we now point master to the old 5.x. Also, there has been some work on async kernel merged since. You may want to update this. Ping @davidbrochart |
|
@SylvainCorlay - I think I'd rather see #428 merged over this PR since #428 would provide a path for Notebook to adopt async kernel management (jupyter/notebook#4479). That said, it's been a while since I've visited this stuff. |
|
FWIW and per my previous comment, I've rebased #428 with master. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a work in progress to allow asynchronous start of kernels,
typically kernel that will be submitted via job queue and for which you
do not know (yet), the host on which they will be running.
This is work in progress, but I'm suspecting we want to push for async
methods in a lot of place, and there is imho no hard in making them
async as they don't have to yield.
We can't (AFAICT) change start_kernel to be async as this would be a
change of API for our consumers.