Forced SIGINT interrupt often required rather than ctrl+C for codes taking a long time

[gaurav-arya]

Update: After learning some more, it seems the issue is that for some codes, one is required to spam ctrl+C to force a SIGINT interrupt rather than simply press ctrl+C once in order to stop it (without killing the whole REPL). Below is one MWE, another MWE is at #48154 (comment) (although seemingly fixed on master).

I've often had particular trouble interrupting code in VSCode and Jupyter Notebook environments: my suspicion is that this is because the SIGINT interrupt way of doing things totally fails in certain cases, and then one has to kill the whole Julia process. Potentially this is an issue with these external tools, potentially it would be helpful to understand why forced SIGINT interrupts are so often needed rather than ctrl+C, potentially it should be easier to trigger forced SIGINT interrupts (including from e.g. VSCode or a Jupyter notebook) since they are so commonly needed,... I'm not sure.

---

I still seem to having this issue on 1.9.0-beta2:

MWE:

function f()
    while true
    end
end

f()

Spamming ctrl+C (edit: the reason this didn't work was because I was in VSCode), holding onto ctrl+C, etc. don't seem to terminate the function for me. Version info:

julia> versioninfo()
Julia Version 1.9.0-beta2
Commit 7daffeecb8c (2022-12-29 07:45 UTC)
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 8 × 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, tigerlake)
  Threads: 1 on 8 virtual cores
Environment:
  JULIA_EDITOR = code
  JULIA_NUM_THREADS = 

Here are a couple of related issues: #46635, #35524. It wasn't clear to me whether this a dup. The former issue is closed, but the fix #47901 should already exist on 1.9.0-beta2 if I am understanding things right?

Also note that in the above MWE, ctrl+C or ctrl+Z does not seem to work at all for me in a reasonable time frame, I need to terminate the REPL. In other cases, also on 1.9.0-beta2, I'm also still experiencing the behaviour where after holding onto ctrl+C / pressing it several times or using ctrl+Z eventually works, but takes some time.

[Seelengrab]

Not sure how you'd expect to interrupt a loop that doesn't yield() anywhere - #47901 is explicitly about making CTRL+C work when sleep is called, which yields to the scheduler internally.

FYI, I can interrupt the loop (though I don't expect it to) with force throwing after the fifth CTRL+C:

julia> f()
^C^C^C^C^CWARNING: Force throwing a SIGINT
^CERROR: InterruptException:
Stacktrace:
 [1] f()
   @ Main ./REPL[9]:3
 [2] top-level scope
   @ REPL[10]:1

julia> ^C

julia> ^C

julia> ^C

julia> ^C

julia> ^C

julia> ^C

julia> ^C

julia> ^C

julia> versioninfo()
Julia Version 1.10.0-DEV.263
Commit f0aed884a1* (2023-01-03 17:17 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: 24 × AMD Ryzen 9 7900X 12-Core Processor
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-14.0.6 (ORCJIT, znver3)
  Threads: 24 on 24 virtual cores
Environment:
  JULIA_NUM_THREADS = 24

[gaurav-arya]

Oh, I guess I don't really understand how interrupts work / when we can expect to interrupt such codes. Feel free to close if it's expected behavior

I guess the pain point for me is that I tend to have to kill the whole REPL if I accidentally end up in such a situation? But maybe that's unavoidable

[Seelengrab]

I'm not saying it's expected, I just think it'd be kind of hard to interrupt such code reliably, since it's just jumping to itself without any scheduler yield points 🤷 If I may, how did you arrive at that code? Surely an empty while loop is not representative of the issue where you encountered this 👀

[gaurav-arya]

Oh, are you saying that the empty while loop is a pathological case, and other cases, such as an infinite running while loop with a nontrivial body, or code that's going to terminate but in a very long time, should generally be feasible to stop with a ctrl-C?

My real examples are generally in the "oops, I made parameters way too large and this code is going to take too long, I want to stop it" category and I quite often find that ctrl-C isn't working and I have to kill my whole REPL. I don't have an MWE for such a case right now, but if you're saying that my current MWE is a pathological case that wouldn't explain why real-world cases have this issue then happy to try and find a better MWE.

[gaurav-arya]

OK, so a minimzed version of where I'm running into issues is:

mutable struct A
    x::Vector{Float64}
end

function f(a)
     a.x .-= 1
end

a = A(rand(1000000))
for i in 1:1000000
    f(a)
end

When I run the above example in the REPL itself, a single ctrl-C does not work on my machine. (If I really minify the above example by getting rid of the struct and func, it does, which is interesting...) Spamming ctrl+C around 5 times in quick succession does force a SIGINT. My hope would be that there is some sort of "expected" way to stop the above code without killing the REPL: if this spamming behaviour can be expected, is it documented anywhere? (If one didn't know to spam ctrl+C, the only solution would be to kill the REPL.)

However, I'm realizing one more thing: when running the above code not in the REPL itself, but rather by ctrl+enter'ing the code from VSCode, I can't even force the SIGINT. That's really the practical problem I'm facing, and perhaps that's a VSCode problem rather than a julia problem so I could file an issue there.

[gbaraldi]

I will say that I can interrupt this on master, so maybe this has already been fixed ;)

[gaurav-arya]

Does both the while loop and my second MWE get fixed on master? And by fixed, do you mean a single ctrl+C suffices? Would be happy to test on master if I knew how, curious what could have changed from the latest 1.9 release:)

[Seelengrab]

And by fixed, do you mean a single ctrl+C suffices?

I can interrupt the empty while loop with force throwing. Your second MWE can be interrupted with just one SIGINT.

[gaurav-arya]

Okay, cool:) If nearly every non-trivial case which usually requires spamming ctrl+C is fixed, then that probably solves things:! But I only have Julia 1.9, so it's difficult for me to test how far things have been fixed beyond that MWE.

As I wrote in the update to the issue body, my main issue with the "spamming ctrl+C" is that this seems to be very often not supported outside the REPL, e.g. in VSCode code running or in Jupyter notebook cells. So having to spam ctrl+C turns into having to kill the entire Julia process. Admittedly, I'm not exactly sure what the precise focus of this issue is and if there's any concrete issue with base/core Julia. Maybe all external tools simply need to make sure they provide the ability to do this forced SIGINT interrupt... or perhaps there is something that can be done in Julia itself to alleviate this.

[andrewjradcliffe]

For me, 1.9 provides the following behavior: second example interrupted with single ^C, first example via 5 ^C's. I use Emacs and vterm, so it's not quite bare terminal.

My naive guess (I know nothing of VSCode) is that this is related to VSCode's abstraction over whatever it considers to be a bare terminal (if it even uses that, or perhaps some other approach to interfacing with a Julia process).
Try launching julia in a bare terminal and testing again.

[gaurav-arya]

On a bare terminal, the second example does still seem to require 5 ^C's on my machine. I'm not sure why, could it be machine dependent?

In general, though, I would like to understand what the "expected behaviour" is: is it expected behaviour to require 5 ^C's for these sorts of codes (the while true end being a common example for all of us). And is it expected for 5 ^C's to always work, or is it also reasonable to be unresponsive? And is this documented anywhere, so that users know about it, and more importantly so that tooling outside the REPL can make sure it's possible to stop the code at all without killing Julia?