From ac519a06cbe14e44c7aa974f0bf07e431f79d064 Mon Sep 17 00:00:00 2001 From: David Brochart Date: Wed, 14 Dec 2022 17:37:16 +0100 Subject: [PATCH 1/7] Add JEP for sub-shells --- kernel-subshells/kernel-subshells.md | 111 +++++++++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 kernel-subshells/kernel-subshells.md diff --git a/kernel-subshells/kernel-subshells.md b/kernel-subshells/kernel-subshells.md new file mode 100644 index 00000000..654ab802 --- /dev/null +++ b/kernel-subshells/kernel-subshells.md @@ -0,0 +1,111 @@ +--- +title: Jupyter kernel sub-shells +authors: David Brochart (@davidbrochart), Sylvain Corlay (@SylvainCorlay), Johan Mabille (@JohanMabille) +issue-number: XX +pr-number: XX +date-started: 2022-12-15 +--- + +# Summary + +This JEP introduces kernel sub-shells to allow for concurrent code execution. This is made possible +by defining new control channel messages, as well as a new shell ID field in shell channel messages. + +# Motivation + +Users have been asking for ways to interact with a kernel while it is busy executing CPU-bound code, +for the following reasons: +- inspect the kernel's state to check the progress or debug a long-running computation. +- visualize some intermediary result before the final result is computed. + +Unfortunately, it is currently not possible to do so because the kernel cannot process other +[execution requests](https://jupyter-client.readthedocs.io/en/stable/messaging.html#execute) until +it is idle. The goal of this JEP is to offer a way to run code concurrently. + +# Proposed Enhancement + +The [kernel protocol](https://jupyter-client.readthedocs.io/en/stable/messaging.html) only allows +for one +[shell channel](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-shell-router-dealer-channel) +where execution requests are queued. Accepting other shells would allow users to connect to a kernel +and submit execution requests that would be processed in parallel. + +We propose to allow the creation of optional "sub-shells", in addition to the current "main shell". +This will be made possible by adding new message types to the +[control channel](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-control-router-dealer-channel) +for: +- creating a sub-shell, +- deleting a sub-shell, +- listing existing sub-shells. + +A sub-shell should be advertised to the client with a shell ID, which must be sent along with +further messages on the shell channel in order to target a sub-shell. This allows any other client +(console, notebook, etc.) to use this sub-shell. If no shell ID is sent, the message targets the +main shell. Sub-shells are thus multiplexed on the shell channel through the shell ID, and it is the +responsibility of the kernel to route the messages to the target sub-shell according to the shell +ID. + +Essentially, a client connecting through a sub-shell should see no difference with a connection +through the main shell, and it does not need to be aware of it. However, a front-end should provide +some visual information indicating that the kernel execution mode offered by the sub-shell has to be +used at the user's own risks. In particular, because sub-shells may be implemented with threads, it +is the responsibility of users to not corrupt the kernel state with non thread-safe instructions. + +# New control channel messages + +## Create sub-shell + +Message type: `create_subshell_request`: no content. + +Message type: `create_subshell_reply`: + +```py +content = { + # 'ok' if the request succeeded or 'error', with error information as in all other replies. + 'status': 'ok', + + # The ID of the sub-shell. + 'shell_id': str +} +``` + +## Delete sub-shell + +Message type: `delete_subshell_request`: + +```py +content = { + # The ID of the sub-shell. + 'shell_id': str +} +``` + +Message type: `delete_subshell_reply`: + +```py +content = { + # 'ok' if the request succeeded or 'error', with error information as in all other replies. + 'status': 'ok', +} +``` + +## List sub-shells + +Message type: `list_subshell_request`: no content. + +Message type: `list_subshell_reply`: + +```py +content = { + # A list of sub-shell IDs. + 'shell_id': [str] +} +``` + +# Points of discussion + +The question of sub-shell ownership and life cycle is open, in particular: +- Is a sub-shell responsible for deleting itself, or can a shell delete other sub-shells? +- Can a sub-shell create other sub-shells? +- Does sub-shells have the same rights as the main shell? For instance, should they be allowed to + shut down or restart the kernel? From d389802464d170b6cbac26f17c8d5e31d3d8bc16 Mon Sep 17 00:00:00 2001 From: David Brochart Date: Mon, 9 Jan 2023 18:31:21 +0100 Subject: [PATCH 2/7] Review --- kernel-subshells/kernel-subshells.md | 65 +++++++++++++++++++++------- 1 file changed, 49 insertions(+), 16 deletions(-) diff --git a/kernel-subshells/kernel-subshells.md b/kernel-subshells/kernel-subshells.md index 654ab802..aadc1ee1 100644 --- a/kernel-subshells/kernel-subshells.md +++ b/kernel-subshells/kernel-subshells.md @@ -8,19 +8,25 @@ date-started: 2022-12-15 # Summary -This JEP introduces kernel sub-shells to allow for concurrent code execution. This is made possible -by defining new control channel messages, as well as a new shell ID field in shell channel messages. +This JEP introduces kernel sub-shells to allow for concurrent shell requests. This is made possible +by defining new control channel messages, as well as a new shell ID field in shell messages. # Motivation Users have been asking for ways to interact with a kernel while it is busy executing CPU-bound code, for the following reasons: -- inspect the kernel's state to check the progress or debug a long-running computation. -- visualize some intermediary result before the final result is computed. +- inspect the kernel's state to check the progress or debug a long-running computation (e.g. + through a variable explorer). +- visualize intermediary results before the final result is computed. +- request [completion](https://jupyter-client.readthedocs.io/en/stable/messaging.html#completion) or + [introspection](https://jupyter-client.readthedocs.io/en/stable/messaging.html#introspection). +- process + [Comm messages](https://jupyter-client.readthedocs.io/en/stable/messaging.html#custom-messages) + immediately (e.g. for widgets). Unfortunately, it is currently not possible to do so because the kernel cannot process other -[execution requests](https://jupyter-client.readthedocs.io/en/stable/messaging.html#execute) until -it is idle. The goal of this JEP is to offer a way to run code concurrently. +[shell requests](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-shell-router-dealer-channel) +until it is idle. The goal of this JEP is to offer a way to process shell requests concurrently. # Proposed Enhancement @@ -38,8 +44,9 @@ for: - deleting a sub-shell, - listing existing sub-shells. -A sub-shell should be advertised to the client with a shell ID, which must be sent along with -further messages on the shell channel in order to target a sub-shell. This allows any other client +A sub-shell should be identified with a shell ID, either provided by the client in the sub-shell +creation request, or given by the kernel in the sub-shell creation reply. The shell ID of the +targeted sub-shell must then be sent along with any shell message. This allows any other client (console, notebook, etc.) to use this sub-shell. If no shell ID is sent, the message targets the main shell. Sub-shells are thus multiplexed on the shell channel through the shell ID, and it is the responsibility of the kernel to route the messages to the target sub-shell according to the shell @@ -55,7 +62,14 @@ is the responsibility of users to not corrupt the kernel state with non thread-s ## Create sub-shell -Message type: `create_subshell_request`: no content. +Message type: `create_subshell_request`: + +```py +content = { + # Optional, the ID of the sub-shell if specified by the client. + 'shell_id': str +} +``` Message type: `create_subshell_reply`: @@ -64,7 +78,8 @@ content = { # 'ok' if the request succeeded or 'error', with error information as in all other replies. 'status': 'ok', - # The ID of the sub-shell. + # The ID of the sub-shell, same as in the request if specified by the client, given by the + # kernel otherwise. 'shell_id': str } ``` @@ -102,10 +117,28 @@ content = { } ``` -# Points of discussion +# Behavior + +## Kernels not supporting sub-shells + +The following requests should be ignored: `create_subshell_request`, `delete_subshell_request` and +`list_subshell_request`. A `shell_id` passed in any shell message should be ignored. This ensures +that existing kernels don't need any change to be compatible with the kernel protocol changes +required by this JEP. + +This means that all shell messages are processed in the main shell, i.e. sequentially. + +Since sub-shells are basically a "no-op", the behavior around +[kernel restart](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-shutdown) and +[kernel interrupt](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-interrupt) +is unchanged. + +## Kernels supporting sub-shells + +A sub-shell request may be processed concurrently with other shells. Within a sub-shell, requests +are processed sequentially. -The question of sub-shell ownership and life cycle is open, in particular: -- Is a sub-shell responsible for deleting itself, or can a shell delete other sub-shells? -- Can a sub-shell create other sub-shells? -- Does sub-shells have the same rights as the main shell? For instance, should they be allowed to - shut down or restart the kernel? +A [kernel restart](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-shutdown) +should delete all sub-shells. A +[kernel interrupt](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-interrupt) +should interrupt the main shell and all sub-shells. From abe92752e518cfe047b038b587846595a028c840 Mon Sep 17 00:00:00 2001 From: David Brochart Date: Fri, 3 Mar 2023 16:55:00 +0100 Subject: [PATCH 3/7] Add alternative solution section --- kernel-subshells/kernel-subshells.md | 39 +++++++++++++++++++++------- 1 file changed, 29 insertions(+), 10 deletions(-) diff --git a/kernel-subshells/kernel-subshells.md b/kernel-subshells/kernel-subshells.md index aadc1ee1..7709618c 100644 --- a/kernel-subshells/kernel-subshells.md +++ b/kernel-subshells/kernel-subshells.md @@ -8,8 +8,7 @@ date-started: 2022-12-15 # Summary -This JEP introduces kernel sub-shells to allow for concurrent shell requests. This is made possible -by defining new control channel messages, as well as a new shell ID field in shell messages. +This JEP introduces kernel sub-shells to allow for concurrent shell requests. # Motivation @@ -23,12 +22,13 @@ for the following reasons: - process [Comm messages](https://jupyter-client.readthedocs.io/en/stable/messaging.html#custom-messages) immediately (e.g. for widgets). +- execute arbitrary code in parallel. Unfortunately, it is currently not possible to do so because the kernel cannot process other [shell requests](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-shell-router-dealer-channel) until it is idle. The goal of this JEP is to offer a way to process shell requests concurrently. -# Proposed Enhancement +# Proposed enhancement: kernel sub-shells The [kernel protocol](https://jupyter-client.readthedocs.io/en/stable/messaging.html) only allows for one @@ -58,9 +58,9 @@ some visual information indicating that the kernel execution mode offered by the used at the user's own risks. In particular, because sub-shells may be implemented with threads, it is the responsibility of users to not corrupt the kernel state with non thread-safe instructions. -# New control channel messages +## New control channel messages -## Create sub-shell +### Create sub-shell Message type: `create_subshell_request`: @@ -84,7 +84,7 @@ content = { } ``` -## Delete sub-shell +### Delete sub-shell Message type: `delete_subshell_request`: @@ -104,7 +104,7 @@ content = { } ``` -## List sub-shells +### List sub-shells Message type: `list_subshell_request`: no content. @@ -117,9 +117,9 @@ content = { } ``` -# Behavior +## Behavior -## Kernels not supporting sub-shells +### Kernels not supporting sub-shells The following requests should be ignored: `create_subshell_request`, `delete_subshell_request` and `list_subshell_request`. A `shell_id` passed in any shell message should be ignored. This ensures @@ -133,7 +133,7 @@ Since sub-shells are basically a "no-op", the behavior around [kernel interrupt](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-interrupt) is unchanged. -## Kernels supporting sub-shells +### Kernels supporting sub-shells A sub-shell request may be processed concurrently with other shells. Within a sub-shell, requests are processed sequentially. @@ -142,3 +142,22 @@ A [kernel restart](https://jupyter-client.readthedocs.io/en/stable/messaging.htm should delete all sub-shells. A [kernel interrupt](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-interrupt) should interrupt the main shell and all sub-shells. + +# Alternative solution: dependent kernels + +Another way of viewing sub-shells is to make them appear as new kernels. The kernel client would +still create a sub-shell through a control message request, but the kernel would then return the +connection information for this "new kernel" in the reply. Only a new ZMQ socket for the shell +channel has to be created, since clients could connect to the existing sockets for the IOPub, +control and heartbeat channels. + +The advantage of this solution is that the sub-shell being viewed as just another kernel simplifies +the changes required in the kernel, which just has to process messages on the new shell sockets, +instead of demultiplexing sub-shell messages from the shell socket using the shell ID in a separate +thread. + +The disadvantage of this solution is that the "new kernels" are not quite independent of the main +kernel, even though they are advertised as such. For instance, if the main kernel is restarted, +clients connected to the dependent kernels will see the kernel restarting too. This complexifies +the life cycle management of the kernel. Also, this solution involves using one more socket per +sub-shell. From 1b19dde7bfd21680465f1c18d2ed8c8ae5247a83 Mon Sep 17 00:00:00 2001 From: Ian Thomas Date: Thu, 8 Feb 2024 13:00:08 +0000 Subject: [PATCH 4/7] Update in line with current kernel subshells proposal --- kernel-subshells/kernel-subshells.md | 205 ++++++++++++++++----------- 1 file changed, 122 insertions(+), 83 deletions(-) diff --git a/kernel-subshells/kernel-subshells.md b/kernel-subshells/kernel-subshells.md index 7709618c..e4f80ff1 100644 --- a/kernel-subshells/kernel-subshells.md +++ b/kernel-subshells/kernel-subshells.md @@ -1,14 +1,14 @@ --- -title: Jupyter kernel sub-shells -authors: David Brochart (@davidbrochart), Sylvain Corlay (@SylvainCorlay), Johan Mabille (@JohanMabille) +title: Jupyter kernel subshells +authors: David Brochart (@davidbrochart), Sylvain Corlay (@SylvainCorlay), Johan Mabille (@JohanMabille), Ian Thomas (@ianthomas23) issue-number: XX -pr-number: XX +pr-number: 91 date-started: 2022-12-15 --- # Summary -This JEP introduces kernel sub-shells to allow for concurrent shell requests. +This JEP introduces kernel subshells to allow for concurrent shell requests. # Motivation @@ -24,53 +24,73 @@ for the following reasons: immediately (e.g. for widgets). - execute arbitrary code in parallel. -Unfortunately, it is currently not possible to do so because the kernel cannot process other -[shell requests](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-shell-router-dealer-channel) -until it is idle. The goal of this JEP is to offer a way to process shell requests concurrently. - -# Proposed enhancement: kernel sub-shells - -The [kernel protocol](https://jupyter-client.readthedocs.io/en/stable/messaging.html) only allows -for one -[shell channel](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-shell-router-dealer-channel) -where execution requests are queued. Accepting other shells would allow users to connect to a kernel -and submit execution requests that would be processed in parallel. - -We propose to allow the creation of optional "sub-shells", in addition to the current "main shell". -This will be made possible by adding new message types to the -[control channel](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-control-router-dealer-channel) -for: -- creating a sub-shell, -- deleting a sub-shell, -- listing existing sub-shells. - -A sub-shell should be identified with a shell ID, either provided by the client in the sub-shell -creation request, or given by the kernel in the sub-shell creation reply. The shell ID of the -targeted sub-shell must then be sent along with any shell message. This allows any other client -(console, notebook, etc.) to use this sub-shell. If no shell ID is sent, the message targets the -main shell. Sub-shells are thus multiplexed on the shell channel through the shell ID, and it is the -responsibility of the kernel to route the messages to the target sub-shell according to the shell -ID. - -Essentially, a client connecting through a sub-shell should see no difference with a connection -through the main shell, and it does not need to be aware of it. However, a front-end should provide -some visual information indicating that the kernel execution mode offered by the sub-shell has to be -used at the user's own risks. In particular, because sub-shells may be implemented with threads, it -is the responsibility of users to not corrupt the kernel state with non thread-safe instructions. +It is currently not possible to do so because the kernel processes shell requests sequentially. +Since the control channel has had its own thread it has been possible to use the control channel +for such interactions, but this is considered bad practice as it should only be used for control +purposes, and the processing of those messages should be almost immediate. -## New control channel messages +The goal of this JEP is to offer a way to process shell requests concurrently. + +# Proposed enhancement: kernel subshells + +The proposal is to support extra threads within a kernel as a JEP 92 +[optional feature](https://github.com/jupyter/enhancement-proposals/blob/master/92-jupyter-optional-features/jupyter-optional-features.md) so that whilst the main thread is performing a long blocking task it +will be possible for other threads to do something useful within the same process namespace. + +When a kernel that support subshells is started it will have a single subshell and this is referred +to as the parent subshell to distinguish it from the other optional subshells which are referred to +as child subshells. + +A new child subshell thread is started using a new `create_subshell_request` control message rather +than via the REST API. Each subshell has a `subshell_id` which is a unique identifier within that +kernel. The `subshell_id` of a child subshell is generated when the subshell is created and +returned in the `create_subshell_reply` message. The parent subshell has a `subshell_id` of `None`. +[Shell messages](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-shell-router-dealer-channel) +include the `subshell_id` as an optional field in the message header to indicate which subshell the +message should be sent to; if this is not specified or is `None` then the parent +subshell is targeted. Use of a `subshell_id` that is not recognised will raise an error. +Subshells are thus multiplexed on the shell channel through the `subshell_id`, and it is the +responsibility of the kernel to route the messages to the target subshell according to the +`subshell_id`. + +Note a kernel that does not support `subshell_id` will just ignore the field if it is present and +run in the main thread. + +[Stdin messages](https://jupyter-client.readthedocs.io/en/stable/messaging.html#messages-on-the-stdin-router-dealer-channel) +will also include the extra optional `subshell_id` field so that it is possible for a subshell to +request and receive stdin independently of other subshells. + +Each subshell will store its own execution count and history. + +## Modifications to existing messages -### Create sub-shell +### Identify optional feature -Message type: `create_subshell_request`: +Clients identify if a kernel supports subshells via the +[optional feature API](https://github.com/jupyter/enhancement-proposals/blob/master/92-jupyter-optional-features/jupyter-optional-features.md): + +Message type: `kernel_info_reply`: ```py content = { - # Optional, the ID of the sub-shell if specified by the client. - 'shell_id': str + ... + 'supported_features': [ + 'kernel subshells', + ... + ] } ``` +The full API for optional features is still to be determined, so the details here may change. +In particular, there is probably the need for a version specifier here to allow future changes to +the kernel subshells specification. + +## New control channel messages + +### Create subshell + +Message type: `create_subshell_request`: no content. + Message type: `create_subshell_reply`: ```py @@ -78,20 +98,20 @@ content = { # 'ok' if the request succeeded or 'error', with error information as in all other replies. 'status': 'ok', - # The ID of the sub-shell, same as in the request if specified by the client, given by the + # The ID of the subshell, same as in the request if specified by the client, given by the # kernel otherwise. - 'shell_id': str + 'subshell_id': str, } ``` -### Delete sub-shell +### Delete subshell Message type: `delete_subshell_request`: ```py content = { - # The ID of the sub-shell. - 'shell_id': str + # The ID of the subshell. + 'subshell_id': str } ``` @@ -104,7 +124,7 @@ content = { } ``` -### List sub-shells +### List subshells Message type: `list_subshell_request`: no content. @@ -112,52 +132,71 @@ Message type: `list_subshell_reply`: ```py content = { - # A list of sub-shell IDs. - 'shell_id': [str] + # A list of subshell IDs. + 'subshell_id': [str] } ``` -## Behavior +Note that the parent subshell (`subshell_id = None`) is not included in the returned list. + +## New fields on existing messages -### Kernels not supporting sub-shells +### Shell and stdin requests -The following requests should be ignored: `create_subshell_request`, `delete_subshell_request` and -`list_subshell_request`. A `shell_id` passed in any shell message should be ignored. This ensures -that existing kernels don't need any change to be compatible with the kernel protocol changes -required by this JEP. +All shell and stdin messages will allow the optional `subshell_id` field in the request to identify +which subshell should process that message: + +```py +content = { + # Optional subshell to process request. + 'subshell_id': str | None, +} +``` + +This field is not in the corresponding reply message as it will be in the parent header. + +### IOPub messages + +All IOPub messages will support an optional `subshell_id` field: + +```py +content = { + 'subshell_id': str | None, +} +``` + +The addition of `subshell_id` in kernel status IOPub messages means that clients will be able to +identify the status of each subshell individually. For an overall kernel-level status these +individual statuses can be combined by the client. + +## Behavior -This means that all shell messages are processed in the main shell, i.e. sequentially. +### Kernels supporting subshells -Since sub-shells are basically a "no-op", the behavior around -[kernel restart](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-shutdown) and -[kernel interrupt](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-interrupt) -is unchanged. +A subshell request may be processed concurrently with other subshells. Within a an individual +subshell, requests are processed sequentially. -### Kernels supporting sub-shells +[Kernel shutdown](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-shutdown) +and [kernel interrupt](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-interrupt) +messages are handled at the kernel (process) rather than subshell (thread) level, and they do not +include a `subshell_id` field. A child subshell can be individually shut down using a +`delete_subshell_request` message. -A sub-shell request may be processed concurrently with other shells. Within a sub-shell, requests -are processed sequentially. +### Kernels not supporting subshells -A [kernel restart](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-shutdown) -should delete all sub-shells. A -[kernel interrupt](https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-interrupt) -should interrupt the main shell and all sub-shells. +These will not claim support for kernel subshells via the optional features API. Unrecognised shell +request messages, such as the subshell request messages listed above, will be ignored as normal. +Any use of a `subshell_id` field in a message will be ignored. Hence existing kernels that do not +support kernel subshells will continue to work as they currently do and will not require any +changes. -# Alternative solution: dependent kernels +## Implications for other projects -Another way of viewing sub-shells is to make them appear as new kernels. The kernel client would -still create a sub-shell through a control message request, but the kernel would then return the -connection information for this "new kernel" in the reply. Only a new ZMQ socket for the shell -channel has to be created, since clients could connect to the existing sockets for the IOPub, -control and heartbeat channels. +Kernel writers who wish to support subshells will need to write extra threading and socket +management code. `ipykernel` will contain a reference implementation. -The advantage of this solution is that the sub-shell being viewed as just another kernel simplifies -the changes required in the kernel, which just has to process messages on the new shell sockets, -instead of demultiplexing sub-shell messages from the shell socket using the shell ID in a separate -thread. +Any client that wishes to create a subshell will have to issue a `create_subshell_request` control +message, and pass the `subshell_id` in all relevant shell and stdin messages. -The disadvantage of this solution is that the "new kernels" are not quite independent of the main -kernel, even though they are advertised as such. For instance, if the main kernel is restarted, -clients connected to the dependent kernels will see the kernel restarting too. This complexifies -the life cycle management of the kernel. Also, this solution involves using one more socket per -sub-shell. +There will need to be some sort of visual indicator for subshells in, for example, the JupyterLab +UI, but this is not strictly speaking part of the JEP. From 1f1ad3d43f24299efb7cc7879cefeee57277906c Mon Sep 17 00:00:00 2001 From: Ian Thomas Date: Thu, 13 Jun 2024 09:24:10 +0100 Subject: [PATCH 5/7] IOPub messages do not need subshell_id as it is in the parent header --- kernel-subshells/kernel-subshells.md | 13 ++----------- 1 file changed, 2 insertions(+), 11 deletions(-) diff --git a/kernel-subshells/kernel-subshells.md b/kernel-subshells/kernel-subshells.md index e4f80ff1..d6ffa307 100644 --- a/kernel-subshells/kernel-subshells.md +++ b/kernel-subshells/kernel-subshells.md @@ -157,17 +157,8 @@ This field is not in the corresponding reply message as it will be in the parent ### IOPub messages -All IOPub messages will support an optional `subshell_id` field: - -```py -content = { - 'subshell_id': str | None, -} -``` - -The addition of `subshell_id` in kernel status IOPub messages means that clients will be able to -identify the status of each subshell individually. For an overall kernel-level status these -individual statuses can be combined by the client. +IOPub messages do not need an extra optional `subshell_id` field as this information is available +in the parent header. ## Behavior From 30058d00a18314da39b473dac6c557575aa1a620 Mon Sep 17 00:00:00 2001 From: Ian Thomas Date: Tue, 13 Aug 2024 14:08:03 +0100 Subject: [PATCH 6/7] Review comment --- kernel-subshells/kernel-subshells.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/kernel-subshells/kernel-subshells.md b/kernel-subshells/kernel-subshells.md index d6ffa307..d3fe3048 100644 --- a/kernel-subshells/kernel-subshells.md +++ b/kernel-subshells/kernel-subshells.md @@ -98,8 +98,7 @@ content = { # 'ok' if the request succeeded or 'error', with error information as in all other replies. 'status': 'ok', - # The ID of the subshell, same as in the request if specified by the client, given by the - # kernel otherwise. + # The ID of the subshell. 'subshell_id': str, } ``` From 5f8bf40ee70b7de4b33a881156a5592a75927b0d Mon Sep 17 00:00:00 2001 From: Ian Thomas Date: Mon, 9 Sep 2024 16:00:40 +0100 Subject: [PATCH 7/7] Update kernel-subshells/kernel-subshells.md Co-authored-by: gabalafou --- kernel-subshells/kernel-subshells.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel-subshells/kernel-subshells.md b/kernel-subshells/kernel-subshells.md index d3fe3048..f88f4a93 100644 --- a/kernel-subshells/kernel-subshells.md +++ b/kernel-subshells/kernel-subshells.md @@ -37,7 +37,7 @@ The proposal is to support extra threads within a kernel as a JEP 92 [optional feature](https://github.com/jupyter/enhancement-proposals/blob/master/92-jupyter-optional-features/jupyter-optional-features.md) so that whilst the main thread is performing a long blocking task it will be possible for other threads to do something useful within the same process namespace. -When a kernel that support subshells is started it will have a single subshell and this is referred +When a kernel that supports subshells is started it will have a single subshell and this is referred to as the parent subshell to distinguish it from the other optional subshells which are referred to as child subshells.