Closed dundalek closed 6 years ago
First, great issue report, makes total sense. I ran this locally and I did eventually see this:
#<ThreadDeath java.lang.ThreadDeath>
user=> ;;;;;;;;;;
; Sorry, have to call Thread.stop on this command.
;;;;;;;;;;
Is it possible that message gets printed for you eventually, just delayed longer than you'd like? There's a 2-second sleep that we could remove to make that cancellation more responsive.
When I wrote this bit in 2012, I think I was worried about Thread.stop
based on the [scary javadoc deprecation warnings](https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#stop()), and the uncertainty around how people might want to use reply
, but these days since nREPL does .stop
and that's the dominant use case for reply
, I'd definitely be open to just deleting this line.
Cool, thank you. You are right, Thread.stop
gets eventually called (I haven't seen it before because the calculation finished before the delay kicked in). And commenting out that line makes it interrupt immediately.
I imagine Thread.stop
could have potentially nasty consequences in a multi-threaded server app so that might be why they discourage it. In the repl it might be probably fine, but I am no expert on the matter :)
Sweet. Want to give me a PR to delete that line? I'm OK with it; otherwise I will get to it at some point.
Steps to reproduce:
lein trampoline run --standalone
(doseq [i (range 1e6)] (println i))
Expected: Computation gets interrupted and the prompt is shown to accept new input. Actual: Computation continues until it finishes naturally.
It is interesting to compare that the nrepl mode (
lein trampoline run
) works as expected and interrupts. I tried both master and latest release tag0.4.1
.I am running Ubuntu Linux, tried it in Gnome Terminal and urxvt, started from bash.
CLJ/Java versions: