Dynamic after Kernel restart/quit:

Question

Bug introduced in V10.1 or earlier and persists through V11.2

[...] The behavior of Dynamics when the kernel quits has never been well defined or documented, although there does appear to be a difference between v9 and v10. [...] I have updated the bug report with your case [...]

---

After quitting the kernel only one Dynamic cell fires. And it does not matter how many are there.

Dynamic[DateString[], UpdateInterval -> 1]

Dynamic[DateString[], UpdateInterval -> 1]

Button["Quit", Quit[], Method -> "Queued"]

When one closes the notebook and reopens it, they work correctly.

• Can I fix this?
• Should I expect this?

Another example shows that custom GUI won't survive kernel quit:

DynamicModule[{init = False}
  ,
  Dynamic[If[! init, "init...", $SessionID]]
  ,
  UnsavedVariables :> {init},
  SynchronousInitialization -> False,
  Initialization :> (
    Pause[1];
    Echo[$SessionID];
    init = True
  )
]

(example from Tracking the progress of Initialization)

Echo confirms intialization fired after Quit[] but the view didn't change.

Win 7/10 V 10/11

p.s. Investigation with LinkSnooper reveals that calls to update DynamicObjects are still being made, just some objects don't care...

Answer 1

Keep in mind it is a toy answer, from my tests it appears it is not general enough.

---

MMA is well designed to fix problems it creates :)

What I've found is that Dynamic aren't stable but Initialization triggers as it should. Let's use it to overwrite it's content when new session occurs:

restartProtect[Dynamic[DateString[], UpdateInterval -> 1]]

restartProtect[Dynamic[DateString[], UpdateInterval -> 1]]

Dynamic[DateString[], UpdateInterval -> 1]

Dynamic[DateString[], UpdateInterval -> 1]

After restart only first two lines will still work.

Here's the code:

restartProtect[expr_] := DynamicModule[{session = $SessionID},
  expr
  ,
  SynchronousInitialization -> False,
  Initialization :> (
      If[
      session =!= $SessionID
          ,
          SetOptions[
              EvaluationNotebook[], 
              DefaultDuplicateCellStyle -> "Output"
          ];
          NotebookWrite[
              EvaluationBox[],
              BoxData @ ReplacePart[
                  NotebookRead[EvaluationBox[]], {1, 1, 2} -> $SessionID
              ]
          ];
          SetOptions[
              EvaluationNotebook[], 
              DefaultDuplicateCellStyle -> "Input"
          ]
       ]
  )
 ]

Answer 2

There are some other interesting aspects with this strange behaviour observed by Kuba.

LinkSnooper shows a bit more. When the option UpdateInterval is used in a Dynamic expression, the clock of the kernel is used. Indeed, each second the kernel sends a message to the frontend, and the frontend starts an update procedure. So what happens when we close the kernel? The kernel cannot send messages to the frontend any more. So it is not surprising that the frontend immediately restarts LinkSnooper. But something has dramatically changed: on my system (windows 7, mma 10.1, 32 bit) LinkSnooper does not show any traffic between the frontend and the kernel and, as Kuba noticed, it is only the first Dynamic that is updated every second.

I do not have an explanation for this, but I happened to find a fix (not really, just some more strange behaviour). Evaluate the two Dynamic Datestring cells. Then scroll in the notebook to a position where the updating cells are no longer visible. Then of course LinkSnooper does not show any updating; only displayed cells are updated.

Close the kernel. The kernel will not be restarted by the frontend. Then scroll back to the Dynamic DateString cells. As soon as they are displayed again, the frontend restarts LinkSnooper. As before, LinkSnooper does not show any activity, but both cells update.

That brought me to another fix: just copy and paste the not running Dynamic DateString cells (switching to and from cell expression is not enough).