From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90663 invoked by alias); 2 Aug 2019 14:46:38 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 90487 invoked by uid 89); 2 Aug 2019 14:46:31 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:942 X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Aug 2019 14:46:30 +0000 Received: from [172.16.0.120] (192-222-181-218.qc.cable.ebox.net [192.222.181.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5A46F1E7CE; Fri, 2 Aug 2019 10:46:28 -0400 (EDT) Subject: Re: [PATCH] Increase timeout in gdb.mi/list-thread-groups-available.exp To: Tom Tromey , Tom de Vries Cc: Simon Marchi , gdb-patches@sourceware.org References: <20190801143855.1640-1-simon.marchi@efficios.com> <87ftmkagwi.fsf@tromey.com> <9cc09b45-ba14-3299-6f99-b738c349ed94@efficios.com> <87tvazisy8.fsf@tromey.com> From: Simon Marchi Message-ID: Date: Fri, 02 Aug 2019 14:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <87tvazisy8.fsf@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-08/txt/msg00046.txt.bz2 On 2019-08-02 9:43 a.m., Tom Tromey wrote: > I'm reluctant to make the test suite more sensitive to the environment > it's running it. Is the reason to do this that the test can time out > normally, and so we'd like to avoid lengthy timeouts? If that's the > case, can the test be fixed somehow instead? > > I guess my mental model here is that a timeout should not matter unless > a test is flaky. But maybe that's naive? I don't know :-) No, the test is not expected to time out under normal circumstances. The advantage of having with_read1_timeout_factor is just that if we happen to break this test and make it time out, we'll have to wait 10 seconds instead of 100 when running without read1. Given that the probability of breaking this test is very small, I don't have a strong opinion on the matter, it doesn't affect the correctness of the testsuite. Simon