<div><br><div class="gmail_quote"><div dir="auto">On Tue, Sep 19, 2017 at 11:51 AM Zachary Turner <<a href="mailto:zturner@google.com">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div>On Tue, Sep 19, 2017 at 11:40 AM Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I must be missing something.<br>
<br>
DisaptchInputInterrupt knows how to interrupt a running process, and because of Enrico's Python interruption stuff it will interrupt script execution at some point but it wasn't very reliable last time I tried it.<br>
<br>
But the whole point of this patch is that in general commands don't listen to that interrupt if they are just running in a loop doing work.  Sending the interrupt is not enough.<br>
<br>
Jim<br></blockquote><div><br></div></div></div><div><div class="gmail_quote"><div>I guess you are saying they installed a custom IOHandler?  IF that's the case, then yea I guess it won't work.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">After some additional thought, I stilled think testing below the sb api layer is more appropriate.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div></div></div></div></blockquote></div></div><div dir="auto">  While Xcode might be going through the SB api, users of upstream lldb (which is what we supposed to be testing upstream) are not.</div><div dir="auto"><br></div><div dir="auto">In order to achieve maximum test coverage and minimal flakiness, there should be 2 tests: </div><div dir="auto"><br></div><div dir="auto"> the first test is for core functionality and tests that if you pass call tge interrupt function, it gets interrupted and the output is as expected.</div><div dir="auto"><br></div><div dir="auto">The second test test checks that if you call the Python api, it calls the function that has been tested by step 1.</div><div dir="auto"><br></div><div dir="auto">If you want a third function that tests both, you can certainly do that, but this way the creation of a test is not blocked on the addition of a Python api.</div>