Make `cancelable in Global := true` the default?

As far as I can tell, everyone loves this feature, so why not make it the default? The only reason I can think of is that it doesn’t seem to work with compile (the shell says “Cancelling execution…”, but nothing is canceled until the compilation completed, and you’re stuck). I see two solutions to that:

1. Make compilation interruptible. There is no fundamental reason that this cannot be done.
2. Make Ctrl+D or some other shortcut (Ctrl+C Ctrl+C ?) quit sbt at any point, just like Ctrl+C does when cancelable is false.

[lihaoyi]

FWIW, with a bit of work you can make anything interruptable, as is done here

https://github.com/lihaoyi/Ammonite/blob/master/amm/repl/src/main/scala/ammonite/repl/Signaller.scala https://github.com/lihaoyi/Ammonite/blob/master/amm/repl/src/main/scala/ammonite/repl/Repl.scala#L154-L161

Yes, it uses deprecated Thread#stop, which may leave your JVM in a borked state, etc. etc. etc.

However, in practice it only leaves your JVM in a borked state on the rare occasion you manage to interrupt the JVM while in the middle of classloading, which is in practice rare (1% of the time? Less). Any application-level mutable-state should get cleaned up by finally blocks; otherwise it would be just as susceptible to being borked by any random NPE or other exception.

Furthermore, when Thread#stop does leave the JVM in the borked state, you restart the JVM. This is exactly the same as you would have to do already, every single time. So it’s a 1% no-difference, 99% strict-improvement.

Ammonite has been using this for 2 years now, and in practice it works really well. Not saying this path is definitely the way forward, but I think it deserves some consideration

[djspiewak]

Adding my two cents…

I’ve had issues with cancelable in Global := true specifically in two areas: concurrency frameworks, and unit test frameworks (e.g. specs2). I haven’t tried recently; specs2 may no longer have these issues. Basically what I was seeing was that the InterruptedException would get caught by some other exception handling mechanism, which would then convert it into some sort of higher semantic failure. In the case of specs2, that failure was reflected in a failed test (while the rest of the specification would continue executing). In the case of concurrency frameworks (at the time, scalaz-stream), it was a bit non-deterministic, but often it would hit a failure recovery mechanism in the application I was running, which would in turn just spin itself back up again.

This all resulted in an experience which was practically unusuable, since it made it impossible (short of kill -9) to actually stop test or run tasks in SBT on that project.