Don't crash on Ctrl-C

[ktdq]

Displaying a large picture will often wait here for the queue to flush and an impatient Ctrl-C will crash the extension.

[codecov]

Codecov Report

Merging #63 (8032932) into master (25e532a) will decrease coverage by 1.13%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master      #63      +/-   ##
==========================================
- Coverage   91.66%   90.53%   -1.14%     
==========================================
  Files           4        4              
  Lines         240      243       +3     
==========================================
  Hits          220      220              
- Misses         20       23       +3     

Flag	Coverage Δ
unittests	90.53% <0.00%> (-1.14%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/core.jl	85.23% <0.00%> (-1.76%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 25e532a...8032932. Read the comment docs.

[davidanthoff]

Hm, that does make me pretty nervous, I have to admit :) But then, that might be more a feature of the underlying InterruptException design... The main question (I think) is whether we can reasonably assume that things are still OK if that exception is thrown, or does that essentially mean all bets are off?

I'm almost thinking that we might want to handle Ctrl+C differently, such that InterruptExceptions can be thrown while user code runs, but not when our own infrastructure code runs. If that is possible is another question...

[ktdq]

The extension is definitely not OK when the InterruptException happens at that location. The REPL is still there, but there's no communication happening with VSCode because the channel is closed, means plotting doesn't work, etc.

Another option would be to restart the VSCodeServer.serve(...) with a new RPC connection when it happens.

[pfitzseb]

I'm almost thinking that we might want to handle Ctrl+C differently, such that InterruptExceptions can be thrown while user code runs, but not when our own infrastructure code runs. If that is possible is another question...

That was the original intent of the current design. At one point I moved the display machinery into the interruptible task for some reason (maybe CUDA not working properly when displaying on a different task or because of inter-task communication being tricky or something, can't quite remember). I'll try reverting that.