Add support for multiple cancellations in Notebook stop button

[DonJayamanne]

When user runs a notebook/cell, the cancel button can be clicked once.
This cancels the CancellationToken passed into the NotebookKernel.executeCell.

In Jupyter, clicking interrupt (stop button) doesn't necessarily work the first time the button is clicked. hence one can click the interrupt button multiple times.

We'd like the same behavior.

I.e. clicking the cancel button should trigger a cancellation (either the cancellation token or a cancellation callback).

It is my understanding that cancellation tokens will not trigger the onCancellationRequested event more than once. Hence the suggestion for a callback or we create a new construct that supports such a notification.

Note: Today we Python extension have a dedicated interrupt button on the toolbar that can be used to interrupt/stop the kernel at any point. We were planning on using the VS Code stop icon, however it doesn't trigger callbacks when clicked more than once.

@rebornix /cc

[roblourens]

Is the interrupt also "per cell" or a global interrupt?

[roblourens]

This also ties into another issue where I suggested a "cancel" method instead of the token so it can live independently of the "executeCell" method

[DonJayamanne]

Is the interrupt also "per cell" or a global interrupt?

In the case of Jupyter kernel, its a global interrupt.
I.e. if you click cancel on any cell or use the command notebook.cancelExecution, it will interrupt the kernel and execution of all cells will be interrupted.

[roblourens]

Does it make sense to still have the cancel button on each running cell, or would it be better to not have it on the cell and only have a global cancel action in the toolbar?

[DonJayamanne]

I think it makes sense to have a cancel button on each running cell.
When running a cell, the mouse is closer to the cell, hence cancelling it would be easy to have a cancel right next to where they initiated the process.

Also, in the case of Jupyter we have a single cancellation for all executing cells. However in other contexts (another implementation) its possible each cell can run in parallel. E.g. if we have a polyglot solution or something like an SQL query, each cell could be completely independent of one another. Hence in such cases I'd like the cancel per cell, as its upto extension authors to handle cancellation.

[roblourens]

Sounds good to me, thanks for the feedback

[roblourens]

Hey @DonJayamanne do you still feel that this is ok?

I think it makes sense to have a cancel button on each running cell.

Also I was wondering, what sort of response do you get when you send the interrupt (eg a user clicks the "cancel" button)? Or is this documented somewhere? eg does the response tell you whether the running cell has stopped executing, or how do you determine whether it was "successful"? Or in other words, whether in vscode you should take the cell out of the "running" state.

Also, in Jupyter what is the difference between running a notebook vs running a single cell? If the user clicks the "run notebook" button, do you instruct the kernel to execute cells one by one? And will cancellation work any different in that case?

I am wondering whether we need a notebook-level execution state to match the cell-level execution state, since right now our model provides total flexibility. Another solution would be to just get rid of the notebook-level cancellation button.

We could have a quick call to discuss if that would be easier for you, sorry for throwing a pile of questions at you.

[DonJayamanne]

g does the response tell you whether the running cell has stopped executing, or how do you determine whether it was "successful"?

We don't get a response indicating it was interrupted.
We wait for the original cell execution to stop.

Also, in Jupyter what is the difference between running a notebook vs running a single cell? If the user clicks the "run notebook" button, do you instruct the kernel to execute cells one by one? And will cancellation work any different in that case?

We run one cell at a time. Cancellation here is still the same.
If we cancel, then we stop the entire notebook execution (i.e. current & all remaining cells stop running)

Another solution would be to just get rid of the notebook-level cancellation button.

I just treat the notebook level and cell level cancellations as a trigger to cancel current execution. So having this at a notebook level IMHO is good. I.e. I'd like this to continue to exist.

We could have a quick call to discuss if that would be easier for you, sorry for throwing a pile of questions at you.

Anything works for me. No worries, please feel free to ping me on teams.

[roblourens]

Notes from our call:

• the API changes work for your scenarios
• The document-level cancel button does the same thing as the cell-level cancel button. When the user executes a single cell, for Jupyter the extension would put the full document in the running state to get the document-level cancel button to show.
• When the document is in the running state, we hide the "Run All Cells" button and show the document-level cancel button
• A Queued state for cells where the cancel button does not appear could be useful for Jupyter, but it's not necessary