Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Await kernel.ready in _async_shutdown_kernel #740

Merged
merged 2 commits into from
Jan 21, 2022

Conversation

jtpio
Copy link
Member

@jtpio jtpio commented Jan 21, 2022

Attempt at fixing jupyterlab/jupyterlab#11886.

According to the comment above:

# If the kernel is still starting, wait for it to be ready.

This branch of the code should be waiting for the kernel to be ready.

This change seems to be fixing the issue noticed in JupyterLab in jupyterlab/jupyterlab#11886.

Example run: https://github.com/jupyterlab/jupyterlab/runs/4894046802?check_suite_focus=true from jupyterlab/jupyterlab#11887

@@ -260,10 +260,11 @@ async def _async_shutdown_kernel(
if self._using_pending_kernels() and kernel_id in self._pending_kernels:
raise RuntimeError("Kernel is in a pending state. Cannot shutdown.")
# If the kernel is still starting, wait for it to be ready.
elif kernel_id in self._starting_kernels:
kernel = self._starting_kernels[kernel_id]
elif kernel_id in self._pending_kernels:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since _starting_kernels is a shim for _pending_kernels defined here:

@property
def _starting_kernels(self):
"""A shim for backwards compatibility."""
return self._pending_kernels

We might as well use _pending_kernels directly.

@jtpio jtpio closed this Jan 21, 2022
@jtpio jtpio reopened this Jan 21, 2022
@blink1073 blink1073 added the bug label Jan 21, 2022
@jtpio
Copy link
Member Author

jtpio commented Jan 21, 2022

Looks like the CI checks have been stuck for a couple of hours.

Gonna close and reopen in a couple of minutes.

@jtpio jtpio closed this Jan 21, 2022
@jtpio jtpio reopened this Jan 21, 2022
@blink1073
Copy link
Contributor

I just kicked a recent build and it passes, so the CI failures are relevant.

@Zsailer
Copy link
Member

Zsailer commented Jan 21, 2022

I can confirm that these hang locally too. Looking into it myself.

try:
await kernel
await kernel.ready
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I see the issue—you are on the right track. The naming of things is getting a little messy.

In this line, kernel is not the kernel manager, like you'd expect. It's the Future returned by _add_kernel_when_ready. Waiting this Future doesn't ensure that kernel has started, it just ensures that the start_kernel method returned. When pending kernels are enabled, start_kernel returns immediately, but the kernel might not be ready. To check that the kernel is ready, we need to call await ... .ready on the actual kernel manager.

Calling .ready on this future is redundant. It might be falsely helping the JupyterLab tests pass because it slows the method enough to dodge the race condition.

Copy link
Contributor

@blink1073 blink1073 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks y'all!

@blink1073 blink1073 merged commit 2c9fbf4 into jupyter:main Jan 21, 2022
@Zsailer
Copy link
Member

Zsailer commented Jan 21, 2022

Thank you, @jtpio, for helping with this! This saved me a ton of time!

@jtpio
Copy link
Member Author

jtpio commented Jan 22, 2022

Thank you @Zsailer for finishing this one!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants