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.

On Tue, 13 Mar 2018 at 02:54, Davide Italiano <dccitali...@gmail.com> wrote:

> On Mon, Mar 12, 2018 at 7:01 PM, Jim Ingham <jing...@apple.com> wrote:
> > The problem with having no timeouts is that you have to then be fairly
> careful how you write tests.  You can't do:
> >
> > while (1) {
> >    print("Set a breakpoint here and hit it a few times then stop the
> test");
> > }
> >
> > 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.
> >
> I see this. So, maybe we should set this to a ridiculously large value
> (e.g. 30/60 minutes)? FWIW, I have at home that's slow enough that the
> testsuite times out more often, and that's not great (the funny part
> is that there's nothing inherently wrong with the tests :) Would you
> be fine with such a middle ground, Jim?
> Thanks,
> --
> Davide
lldb-dev mailing list

Reply via email to