or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Do you want to remove this version name and description?
Syncing
xxxxxxxxxx
Kernel Status Cleanup
Existing Implementations
Jupyter Client
The messaging spec defines the following execution states:
('busy', 'idle', 'starting')
Jupyter Server
Jupyter Server is providing the following states as
execution_state
:('busy', 'idle', 'starting', 'dead')
It starts out as "starting" and is dangled on an
execution_state
attribute of the kernel manager. Then it is updated by watching iopub. It adds adead
state when a kernel manager has aready
promise that errors. In that case it also adds areason
attribute to the model that the front end can use to display an error.JupyterLab
JupyterLab defines the following statuses:
It updates the status based on
iopub messages
, or manually in the case ofautorestarting
andrestarting
. It usesunknown
at startup or when we are not connected. Thedead
status is both handled internally and when thereis a
dead
execution state given when fetchthe kernel model after a failed websocket connection.
The
terminating
state was added in jupyterlab#8562 but it is only used by theSessionContext
in astatusChanged
signal, but it does not expose astatus
property.JupyterLab also has a ConnectionStatus that reflects the state of the WebSocket connection.
Proposal
Jupyter Client should preserve the existing
execution_state
semantics, and do its own tracking, offering anexecution_state
property.It should add a
status
field reflecting thestatus of the subprocess. It should remove the
ready
promise, but preserve theuse_pending_kernels
option. It should alsohave an API for waiting for a state to move into
a desired state. It should also offer a "reason"
property for when it enters a dead state.
Jupyter Server should continue to provide the
underlying
execution_state
in its kernel model,but also provide the
status
property if it isavailable. When using pending kernels and connecting to a websocket, it should use the
new Jupyter Client API to wait for the state to
be finalized.
JupyterLab should use the new "status" and
"reason" model fields instead of doing its own
internal handling of kernel status. It should separate the concept of execution_state from kernel status. In the case
where a WebSocket connect errors, it should update its status from the status field if given
and the reason field if given. It should deprecate any statuses that would not have
been provided by Jupyter Client and add handling
for new ones as appropriate.