<div dir="ltr">I think we should get some data before pulling numbers out of our sleeves. If we can get some numbers on the slowest machine that we have around, then we should be able to specify the timeout as some multiple of the slowest test. For example, for me the slowest test takes around 110 seconds. The timeout is 4 minutes (~ 2x) and I don't get tests timing out. How long does the slowest test take for you? If we set the timeout as 3x or 4x that number, we should create a sufficiently large buffer and still avoid half-hour waits.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, 13 Mar 2018 at 02:54, Davide Italiano <<a href="mailto:dccitaliano@gmail.com">dccitaliano@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Mar 12, 2018 at 7:01 PM, Jim Ingham <<a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a>> wrote:<br>
> The problem with having no timeouts is that you have to then be fairly careful how you write tests.  You can't do:<br>
><br>
> while (1) {<br>
>    print("Set a breakpoint here and hit it a few times then stop the test");<br>
> }<br>
><br>
> because if the breakpoint setting fails the test can run forever.  And we wait forever to launch or attach to a process internally in lldb, so if you mess up attaching or launching in some situation, that again makes the test run forever.  The timeouts are a backstop so you will get useful results from the testsuite in the case of this sort of error.<br>
><br>
<br>
I see this. So, maybe we should set this to a ridiculously large value<br>
(e.g. 30/60 minutes)? FWIW, I have at home that's slow enough that the<br>
testsuite times out more often, and that's not great (the funny part<br>
is that there's nothing inherently wrong with the tests :) Would you<br>
be fine with such a middle ground, Jim?<br>
<br>
Thanks,<br>
<br>
--<br>
Davide<br>
</blockquote></div>