Handling CTRL-C in sbt console
Paweł Wiejacha
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....@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?
Regards,
Paweł Wiejacha.
Josh Suereth
What I would do, I think, is leave the global handling and allow tasks to have more specific handling.
One issue is that you can't guarantee that there's only one task running. For things like test, we could also have a compile running somewhere.
Right now the current strategy is simple, but it works in that scenario.
I'd be cool if we had a mechanism for tasks to optionally provide a cancellation strategy which is tried before the "nuke everything" strategy. You could use the act command to first check if the task provided a rich cancellation strategy and if so nest it under the default. Then you could still use the nuke the world strategy in case the task-specifix one isn't working and the user is still pressing Ctrl+c
If you need pointers/help feel free to chat on http://gitter.I'm/sbt/sbt
--
You received this message because you are subscribed to the Google Groups "sbt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbt-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sbt-dev/53c69ce8-2b61-4c2d-96fc-067930e69b63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.