gistfile1.txt

Hello,

Together with Anna Stępień and Maciej Biłas we started working on the following issues:
- https://github.com/scalatest/scalatest/issues/97
- https://github.com/sbt/sbt/issues/228

We decided to focus on handling CTRL-C during test execution in sbt console.

As for now we:
1. Created Stoppable interface in sbt.testing (test-interface)
2. Changed ScalaTest ScalaTestRunner so that it implements Stoppable interface. Currently stopping ScalaTestRunner does not stop/kill running test cases but new test cases/suites
are not executed.
3. We changed sbt so that SIGINT is intercepted and tests are stopped.

But then incidentally we found Signal (in util/collection/src/main/scala/sbt) and TaskCancellationStrategy.Signal that was introduced by:

commit 2686acd99326d99bf2f17a488858d6df5e27d52a
Author: Josh Suereth <joshua.suereth@gmail.com>
Date:   Mon Apr 7 16:42:08 2014 -0400

    Part #1 of cancel-task-hooks - Hooks EvaluateTask.

a year ago. And we found that after setting `set cancelable in Global := true` CTRL-C interrupts threads related to the task that's being executed.

Our idea was CTRL-C should stop executing new test cases and then (e.g. after second CTRL-C/some timeout) interrupt TestingFramework threads because interrupting threads is quite dirty in our opinion. 

But maybe interrupting threads is the right thing to do - it's dirty but it's also simple and works for all kind of tasks, not only for `test` task.

What do you think is the better strategy?

For example, pressing CTRL+C when the `console` task is executed leaves the SBT console in an untidy state (SBT 0.13.7, Scala 2.11.5). We think that having a cancellation strategy per task type makes it easier to keep a clean SBT session state.

How do you imagine SBT behaviour after pressing CTRL+C, for example clearing the prompt line, exiting console when line is empty, stopping compilation?

Do you think it's worth the effort to implement custom task cancellation handling?