<div dir="ltr">+1 On deleting the lldb-mi tests and increasing the timeout.<div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 14 Mar 2018 at 02:27, Jim Ingham <<a href="mailto:jingham@apple.com">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">It is unfortunate that we have to set really long test timeouts because we are timing the total Test class run, not the individual tests.  It is really convenient to be able to group similar tests in one class, so they can reuse setup and common check methods etc.  But if we're going to have to push the timeouts to something really long because these tests get charged incorrectly, which makes this strategy artificially less desirable.<br>
<br>
When we spawn a dotest.py to run each test file, the runner that is doing the timeout hasn't ingested the test class, so it can't do something reasonable like count the number of tests and multiply that into the timeout to get the full test timeout.  I tried to hack around this but I wasn't successful at getting hold of the test configuration in the runner so you could figure out the number of tests there.  If somebody more familiar with the test harness than I am can see a way to do that, that seems like a much better way to go.<br>
<br>
But if we can't do that, then we can increase the overall timeout.  Though we might want to override that with LLDB_TEST_TIMEOUT and set it to something lower on the bots.<br>
<br></blockquote><div><br></div><div>Counting the test methods would be a bit tricky, I believe. I think that a slightly more feasible solution (although it would still require some rearchitecting) would be to base the timeout on the last message received from the "inferior" dotest instance. Each dotest sub-process opens up a socket to communicate the test results to the master process. We could use this as a liveness indicator, and base the timeout on the time elapsed since the last message. This is still a bit tricky because right now the timeout logic is in a completely different place than the communication code, but this could be fixed (if someone feels adventurous enough).</div><div><br></div><div>cheers,</div><div>pl</div></div></div>