Notebook: The asterisk for "busy cell" is ambiguous

[ymost]

When a cell is displayed as "busy" with an asterisk, it can mean one of several things:

1. The cell is currently executing.
2. An "execute" command was sent to the cell, but another cell is currently executing. The cell will execute when its turn comes.
3. The kernel was interrupted / restarted while the cell was executing, it is currently not executing.

(There might be another scenario that I'm missing here.)
This ambiguity makes it hard to handle notebooks with cells that take some time to execute and are sometimes queued or interrupted. It's hard to understand the current execution status. Often I find myself returning to a notebook and not remembering if the cell is still executing or not.

It would be great to have some way to distinguish the above cases, maybe by using a different symbol for each one instead of using an asterisk for all of them.

[Carreau]

The cell is currently executing.
An "execute" command was sent to the cell, but another cell is currently executing. The cell will execute when its turn comes.

With current architecture there is no way of distinguishing. From the point of view of the notebook it's the same. All the messages are in zmq-queue. It will be really hard to distinguish.

The kernel was interrupted / restarted while the cell was executing, it is currently not executing.

That's a bug. It might be hard to fix depending on the case. If computation was interrupted * should be cleared.

I think this goes a a more general refactor of the notebook format and the "dirty" status, where we would need to have an execution "submitted" timestamp and compare that to last kernel execution reply.

[ymost]

Thanks for the reply!
Distinguishing only the last case (kernel interrupted / restarted) will be really useful for me. I'm surprised to hear this is considered a bug, as I Interrupt / restart the kernel often and the asterisk is almost never cleared. I would be really happy if that were fixed.

[takluyver]

Milestoned this as being for 5.1 so we can look into fixing that.

[dela3499]

Another case: cell that has completed executing, but precedes currently executing cell.
I run into this when I shift-enter multiple cells to execute many things in a row. I've noticed the first cell will execute and print an output, but the asterisk remains while the next cell executes.

[gnestor]

The kernel was interrupted / restarted while the cell was executing, it is currently not executing.

@Carreau Would a fix for this involve resetting the _busy_ state for all cells when the kernel is interrupted or reset?

[blink1073]

We don't know for sure if the kernel was successfully interrupted, only that we attempted to do so, right?

[Carreau]

And it should already reset. There is a weird race condition somewhere that sometime fails. We just haven't really figured that out.

[gnestor]

Marking as 5.2 to give us more time to figure out why cell busy state is not reset on interrupt/restart kernel sometimes...

[takluyver]

I think the part we want to fix about cells that are left 'busy' when the kernel is restarted/interrupted/dead is a duplicate of #2460. Since that one's got some recent activity, I'm closing this.