jingham accepted this revision. jingham added a comment. I don't quite understand the comment about signals adding indeterminacy. No signal delivery is required to test this part. The lldb driver has a sigint handler that calls SBDebugger::DispatchInputInterrupt. But since you aren't testing whether SIGINT actually calls DispatchInputInterrupt, you can just call it directly. I was suggesting executing a command (with SBCommandInterpreter::ExecuteCommand) for a Python command that cycles calling WasInterrupted. Then you would make another thread in Python and have that thread wait a bit then call DispatchInputInterrupt, If "wait a bit" bothers you then you could have the python based command you are interrupting signal the interrupting thread before going into its loop. I don't see how this would result in indeterminacy, And it would be testing exactly what you want to test: does calling DispatchInputInterrupt cause a command in flight to be interrupted.
But this change is fine. Check it in and I'll add a test when I get a chance. https://reviews.llvm.org/D37923 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
