Ctrl+c fails to interrupt many functions. What makes a function interruptible?
That’s a good question. Generally you can “try” to catch it using something like this:
try ... catch err if typeof(err) == InterruptException ... end end
but it was always unpredictable in the past and it is still confusing (at least to me) in 1.8.0, see e.g.
- Cannot safely exit Pluto on Windows + git bash · Issue #2136 · fonsp/Pluto.jl · GitHub
- Ctrl-C in script: atexit is ignored
- Cannot catch Ctrl-C gracefully in this script - #4 by chunjiw
and so on.
The problem is – as far as I understood – that the SIGINT is sometimes hold back by some other code which may prevent to reach your desired try-catch. It may even end up in nirvana so that the
InterruptException is never bubbling up, although all background tasks have finished and the program is in an idle state waiting for any kind of input whatsoever.
I remember some discussions many years ago where more details were revealed but I cannot find them. Performance is btw. one of the reasons you cannot have instant interruption, since you would need to regularly check for signals during runtime, so it’s always a trade-off between those.
Is there a parameter to tune this trade-off? Even if it has to be at the process-level, and not any more fine-grained, it would be useful to be able to say “I’m willing to take a performance hit for the sake of responsiveness to interrupts”.
+1 on that, especially when you’re at the beginning exploring solutions to your problem. Many times I had to kill julia completely and then wait again and again for startup and compilation…
I think if you add a call to
yield() in any inner loops, that can help. But if those loops are in other package’s code then that’s not as feasible.
The problem is that foreign code can get into states and loops where the interrupt is not checked, so I would guess there is no way, but I hope someone with more insights will answer