<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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::</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">DispatchInputInterrupt.  But since you aren't testing whether SIGINT actually calls DispatchInputInterrupt, you can just call it directly.  </span></blockquote><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Agreed.</span></div><div><span style="font-size:12.8px"><br></span></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">I was suggesting executing a command (with SBCommandInterpreter::</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">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.</span></blockquote><div><br></div><div>Once you have a second thread you end up with the non-determinism I hinted to (this is true regardless if you hardcode a wait, use an event or keep interrupting at a fixed rate). Now this is not a deal breaker in itself, after all if you go after testing async behavior it's part of the deal.</div><div><br></div><div>But in this case it gets a bit more complicated as far as I can tell: first, DispatchInputInterrupt() is only passed on the top IO Handler, if any. So DispatchInputInterrupt() through SBDebugger is not exactly the same as a real input interrupt.</div><div><br></div><div>Second, if we want to allow the interruption of commands that are executed through SBDebugger::HandleCommand() the command state machine is not a simple idle -> executing (->interrupted) -> idle since you get reentrancy (the command can invoke other commands, etc...). Note that in the current version, the states are only tracking in CommandInterpreter::IOHandlerInputComplete() which should not lead to reentrancy (I did manual testing for this - if anything I'd love a way to automate testing _this_ part btw)</div><div><br></div><div>I got pretty far in dancing around all this, but it become clear that I was not really testing the real path and I was just introducing more artificial complexity. If I'm missing anything I'd be happy to be revisit this and to be proven wrong.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 20, 2017 at 3:51 PM, Jim Ingham via Phabricator <span dir="ltr"><<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">jingham accepted this revision.<br>
jingham added a comment.<br>
<br>
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::<wbr>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::<wbr>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.<br>
<br>
But this change is fine.  Check it in and I'll add a test when I get a chance.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D37923" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D37923</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div></div>